Life Expectancy of Slackware x86 i586
 

Most new devices have seen 32-bit come and go.
There are no new 32 bit desktop processors being made by the two companies making desktop processors in 2017.
I would venture to see a 32 bit like Alein Bob's merged into slackware.
I do not get it the only thing I am needing 32 bit compat for now days is do to VIVOX.
I own a license to it for gaming. Unfortunately the lead DEV was unable to install ubuntu to compile very small amount of code.
so I have to run VIVOX in WINE for my Linux voice . And am right now working on a true 64 bit wine Plugin for that voice.
Steam has created there own voice do to this. and will let you use it also.
So why the big 32 bit Slackware.

Is vivox just for voice-chatting with headsets?

You could use something else...

Like Discord...

https://github.com/duganchen/my_slac...ord.SlackBuild

Well, because not every person in the world has the availability of 64 bit processor computers or similar offerings. If all one has is a 32 bit PC, to say an example, then, they should have the possibility and availability of an OS that allows them to work just as well as they could with any 64 bit one.

Slackware is about choice, and having the possibility of seeing any old computer being revived is a joy that can't be described in words. Having more options and possibilities is always a thing I look up to, not less. If I wanted less options and less control I would be using Windows for that matter (which still has 32 bit offerings for their latest OSes)

Sorry for the off-topic but Drakeo, did you consider mumble and murmur? Both have a SlackBuild @ SBo.

Also Google's GMail Skype clone, Hangouts, is quite good and being browser based (like one version of Discord) is basically compatible everywhere with everything.

https://hangouts.google.com/

And I heard that Google's newest video calling app called Duo is now available for PC as well and can be run in Chrome.

Life Expectancy of Slackware x86 i586
 

If you are doing any type of serious gaming, you should be using discord. An alternate option to that is mumble because some administrators want more control over their comms.

Hangouts or duo might work, but not everyone wants to rely on Google for such a thing. You might as well use Skype in such a case.

There is a reason pro gamers use discord. Just my experience and 2 cents.

Sure, so machines with 2 year old hardware won't be 32bit. What about all the other hardware that existed before that?

And do you plan on completely dropping 32bit support or rolling it into 64bit Slackware and make it multilib out of the box (which Pat has stated many times won't happen)? If 32bit support is dropped, where do you think Eric will get his 32bit packages he converts into compat32 packages? I doubt he will take the time to maintain a 32bit OS, just so he can pull the handful of packages over that he has made available for multilib users. If Pat does switch Slackware64 to a true multilib (he won't), where do you think he will get the 32bit libraries to include with Slackware64 to ensure multilib works properly?

Most likely, if Pat stops supporting 32bit Slackware, I imagine multilib Slackware will die as well -- unless someone forks 32bit Slackware and then Eric uses those packages to maintain his multilib packages.

I've been running Slackware64 since 13.0 was released. I haven't run 32bit Slackware since I switched to Slackware64. However, I realize that my usage is not the same as others, and the hardware available to me isn't the same as what's available to others. Many on the forum still run 32bit Slackware, some even on 64bit hardware.

And, I gotta ask... why do you want 32bit Slackware gone? Do you feel it is holding back Slackware64? Do you think Pat's time would be better spent on only working on Slackware64? I'm truly curious... From my understanding, almost all packages compile the same on 32bit as they do on 64bit. So for most of the time, the only thing that is used by maintaining a 32bit version is machine time, for Pat to run the compiles on his 32bit machines.

As frustrating as it is to say this, almost 10 years after Slackware64 was released with 13.0, some of the Linux ecosystem is not ready for pure 64bit distros. Gaming would be the one hit particularly hard since Steam still requires multilib.

Wow wonderful replies. well 128 bit is about 20 years out for consumer the gcc 4.6 and up have the ability to build 128 bit.
I just think the load of Slackware is huge.
I think 32bit will be around for a while longer. Nvidia said they stop it. But big money Steam is supporting
32 bit client for Linux to run many windows games. So as you see 32bit still around for AMD and Nvidia.
I think it is a money issue and resources towards it.

This week some insurance company had all the videos in flash. I think that would be ok
if the video was interactive like many. none of the employees could watch the
video on Android. so I had to grab it and convert it and post it for employees.
it is about change and who is paying the bill.
Like I said huge demand of Pat's resources keeping it up.

I build all my compat32 from 64bit slackware. little bit of work for about.
75 packages. Pat is doing it for about ????
slackware 10.2 was my favorite :)

Oh yes I have embedded that several times in my work mumble is a nice voice client just getting the herd of sheep to use it.
it is an option on opensimulator. Tell you the truth it works well. but the mass users are using a client with vivox.
and the mass are windoze users.
I see a future in Steam voice client do to the dev team wanting it to work on multi platforms.
yes it is an api that allows private voice and multi group voice for gaming.
I think when they drop Linux steam asked for the blob and they said no. So steam built there own.
yes the build tools for google was built for x86 cpu's and the ARM cpu. They build in x86_64. for both.
Pretty much because they support the devices they market.

Got to love it hehehehe.
It would be nice for parallel building have devs use NPROC=$(nproc) make -j$NPROC
been using that a long time. I see Pat pulled that in. qt5 at -j1 get coffee hehehe and a beer. and a vacation.

Do we know if there is much extra burden for building/maintaining 32bit Slackware? I can only remember of a few instances in the last several years when Pat stated that something wasn't working in either 64bit or 32bit (most likely, the latter, but I don't remember).

For all we know, he just uses something like parallel ssh to run commands on two different build machines (or VMs) to spawn off the 32bit and 64bit builds simultaneously.

While there likely aren't many people installing 32-bit Slackware as their main OS today, there are probably quite a lot of people running 32-bit software under Slackware64 who need to grab packages from 32-bit Slackware.

I've also had things just fail to build under multilib Slackware64 and had to resort to a VM running Slack32 to keep it from tripping over 64-bit libraries.

It's not the hardware, it's the software. It's too soon for 32-bit to go away, unfortunately.

I still have a secondary install of 14.2 32bit that I upgraded from 14.0 32 bit. At the time there were some multimedia oriented plugins that required it and much of Wine still does, which is likely why Steam will for a time. I haven't used it in a few months since most works in multilib now at similar or better performance, excepting some older games I have to run in Wine. Recently though it did come in handy as a local library source for building a couple compat32 files for my Main, multilib 14.2.

I don't see any huge increase in performance with 64 bit overall, nor did I expect much. I do understand the push though for some applications. Ultimately it will be easier and likely better when everything is 64 bit but I agree with zuriel, it is still too soon for 32 bit to die off.