Do you require 32bit compatibility in Slackware64-current?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
View Poll Results: Do you require 32bit compatibility in Slackware64-current?
I "need" the 32-bit compatibility to run the few apps I use under WINE (PokerStars, MS XL, MS Word, and games, of course), but am fine getting that layer into place myself.
First off, the heavy lifting is already done by slamd64, and they have generously already put up the most essential compatibility libraries under the salckware64-current folder on their FTP mirrors.
To get wine 1.1.22 to build with all of the features fully intact on slackware64-current, I had to install all of the previously mentioned slamd64 packages and then build another dozen or so 32-bit libraries myself. Everything works GREAT. I was surprised how much of a performance improvement there was from 32-bit Slackware 12.2 to 64-bit Slackware-current, even in WINE apps running in 32-bit mode. (go figure)
I didn't have to be an expert, though, as WINE very graciously reported at the end of its configure which features would not be enabled until I built the appropriate libs and reconfigured the source.
In my experience, Slackware devotees are among the leetest of the leet, so weather or not the official Slackware 13 64-bit includes a complete set of compatibility libs, I'd expect most to be able to fend for themselves if they need them, and that the community of slackers will quickly provide some tgzs on linuxpackages.net for those who cannot.
An operating system is to serve applications, not applications to serve operating system.
You may be right, but we should make those who are not able to catch up obsolete, in order to move things forward. Why do we need a 64bit OS if it's supposed to run 32bit applications mainly?
You may be right, but we should make those who are not able to catch up obsolete, in order to move things forward. Why do we need a 64bit OS if it's supposed to run 32bit applications mainly?
If you do not require 32bit applications then you are in the fortunate position to have a wholly 64bit experience, but making 32 bit applications obsolete is just a touch of overkill. Let us explore the fact that about 40% of people require to have 32bit compatibility, but I would guess that not one of them needs to run mainly 32bit applications.
Hardware on the whole is now only sold as 64bit. This means that to make the most of your hardware you need a 64bit OS, unfortunately not all applications are available in 64bit that usually means that you either change the application that you use or you find someway of running that application as a 32bit variant.
In my case I run Quicken, by using wine. This needs to be 32bit. I could move to Gnucash or another 64bit Linux application, however I choose to use a Windows program, even though I have been 100% Linux for about 8 or 9 years, as it is has a report that I need that no one else seems to do.
If wine was made obsolete I would have to move to another OS as the accounts package is the most important program on my computer. So I think that you should consider the 40%, can we not benefit from 64bit also, at least for the majority of the time.
I think these arguments are moot as long as the Slackware team maintains the 32 bit release along with 64 bit. If you think that moving to another distro will solve your issues then that too is your choice.
Everyone is free to maintain their system in the fashion that they wish. But as 'Slackware64 -current' is going then I feel the team will release a great stable distribution as they always have. Thus allowing the flexibility to choose as one wishes. Patience!
I quite agree, my argument was merely to show that some people have to have certain programs, and that it is not always best to be only black or white.
I actually have Quicken working perfectly on Slackware64-current and I was only grand-standing.
In my case I run Quicken, by using wine. This needs to be 32bit. I could move to Gnucash or another 64bit Linux application, however I choose to use a Windows program, even though I have been 100% Linux for about 8 or 9 years, as it is has a report that I need that no one else seems to do.
samac
Quote:
Originally Posted by foodown
I "need" the 32-bit compatibility to run the few apps I use under WINE (PokerStars, MS XL, MS Word, and games, of course), but am fine getting that layer into place myself.
First off, the heavy lifting is already done by slamd64, and they have generously already put up the most essential compatibility libraries under the salckware64-current folder on their FTP mirrors.
To get wine 1.1.22 to build with all of the features fully intact on slackware64-current, I had to install all of the previously mentioned slamd64 packages and then build another dozen or so 32-bit libraries myself. Everything works GREAT. I was surprised how much of a performance improvement there was from 32-bit Slackware 12.2 to 64-bit Slackware-current, even in WINE apps running in 32-bit mode. (go figure)
samac,
I do a lot of gaming. Just with the slamd64 compatibility packages, I could build a WINE (with no fancy options, just './configure;make dep && make; make install') that could run Word and Excel. I'll bet Quicken would run on a basic build like that too.
I actually have Quicken working perfectly on Slackware64-current and I was only grand-standing.
I suck and should read down two posts before replying to one.
To partially justify myself, I will say that I agree with you, samac. I would MUCH prefer 'official' Pat-approved 32-bit compatibility in Slack64v13. It just keeps the distro mailable for whatever folks want to do with it . .. which in (probably more cases than not) some cases means running the odd 32-bit windows prog.
I doubt that when 64bit slack is at long last released it will be any less capable than the other 64bit slack-like distros
(this is slackware we build everything not included in the distro from source anyway)
all the 64bit slack-like distros have had 32bit libs for a long time one way or another
I don't need 32 bit capability. I have waited a long time for Slackware64, and I intend on being pure 64 bit. I may someday have to eat those words, but not today.
I think this sums it up for me, though I have not yet read this entire thread (nor much of anything else yet about it) due to being on my way out the door here but *just* got wind of 'Slackware64' and I must say "WOOOOOHOO!!!" it's just what I have been waiting for and extremely look fwd to its 1st stable release.
AFAIK I don't **need** 32-bit compatibility.. But then, lol how will I know? Heh heh, that's the fun of it, in part.
Surely us Slackers can and will find a way to advance cleanly, ultimately with Slack64 being 100% 64bit, but meanwhile, I won't complain regardless what PV decides to do for now; I am happy that there will FINALLY be a way for me to use the 64bit-ness of my machine, _without_ not using Slackware any more.
(Sorry for the rant/ramble; I'm just excited
.. Oops, did I even vote yet?? Here goes!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.