Do you require 32bit compatibility in Slackware64-current?

I use wine to run a single Windows program (Quicken) on Slackware 12.2. As I have a 64bit computer I would like to run a 64bit version of Slackware and be able to run wine within that OS without having to use a virtual system.

I feel that it would be overkill to run a virtual 32bit system in order to emulate a different OS, just to run a single program.

In order to do this I would need 32bit compatibility libraries included in Slackware64-current.

This poll is a simple yes/no, and as such I would appreciate it if answers could be limited to yes/no and maybe the 32bit program that you have to use.

Do you require 32bit compatibility in Slackware64-current?

Yes I do. But I think it might be better to use chroot to do it. When it comes time and its nearly ready, it would be nice if someone wrote a howto for doing this. I may write it if I figure out how to do it.

Hi,

Originally Posted by samac <snip> Do you require 32bit compatibility in Slackware64-current?

No, I don't require 32bit for 'Slackware64® -current'. I have 'Slackware®' which is a pure 32bit. Make the changes you need to accomplish your tasks. This is not M$ and I for one don't want to get into the spiral of keeping things compatible all the way back. There are times to have parallel systems or the availability of having them. I think 'PV' has made the choice to work in this way a long time ago. I for one support his choice. That's why I continue to use Slackware®.

I just wish people would understand this is 'Slackware64® -current' and is in the testing phase. Maybe at some point 'PV' will make the choice of 32bit support for 'Slackware64® -current'.

Sorry, if I didn't meet your criteria but this is a forum.

onebuck

Thanks I appreciate your comments, however I am sure you will agree that customer feedback is one way of generating change. Democracy and free speech after all go hand in hand. After all how will PV, Alien Bob et al. know what people want if we do not tell them.

samac

I have decided to vote, and voted no, despite my misgivings that this poll has the potential to be divisive. I also worry that the results might be used to pressure the Slackware developers.
I agree with onebuck. I do not believe in the "grand unified operating system" that will be all things to all people.
For the moment I am maintaining three Slackware partitions on my home system.
1. Slackware 12.2 - To be the same as on the servers at work that I administer.
2. Slackware32-current - So that I can build packages for my 32bit processor laptop and to be able to run 32 bit apps such as WINE, although if I really want to run a Windows app then I do so natively.
3. Slackware64-current - So that I can fully utilise the power of my 64bit processor and so that I can use code that is only available for 64bit architecture, (I can finally run a module within R that could not be used in 32bit Slackware!) as well as staying in touch with the progress of personal computing.

This is a time of transition, as has already occurred with going from 8bit to 16bit and then 16bit to 32bit architectures. The hot air is always the same. My feeling is that the best approach is to break cleanly from the past and embrace the new. I see no need for 32bit compatibility. Arguments along the lines of "but I cannot run application XYZ" just show a lack of willingness to adjust to change or to look for alternative approaches. If you really need to run some legacy application that is so important, then you will happily maintain a dedicated system to do so.

I know no comments were requested, but...
Slackware 13.0 = pure 32 bit
Slackware64 13.0 = pure 64 bit
Slamd64 13.0 = multilib
...is how everything should work out...I think?

Thanks for the poll, Samac. Good idea.
I want one operating system and one operating system only on my computer and I expect it to do all that I need to do. I do not want to dual or triple boot. I do not want to have to run a virtual machine to run a windows program. Therefore, , I would like Slackware64 to be multi-lib and have the option to install all the necessary files to make it so at the time of the initial installation.
Yes, I know it is now "current" and things may change before the final release.
Just my two cents on the subject.

I would like to have it (as an extra addon is the same).

it should be nice to have a 64bit desktop/server that can run Wolfenstein Enemy Territory, that's why I got still 32bit slack at home

btw, hi to everybody, may the slack be with you!

I think that people should be pushing the makers of 32-bit only products to release in 64-bit. Why is an OS to include OBSOLETE software instead of asking the software makers to upgrade their products? It would be a win/win. We get a 64 bit product, OS doesn't need to include extra libs (extra work) and we are moving forwards, not remaining stagnant. Make a petition with the software makers, not with the OS maker.

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.

A third option of "I don't know" is missing.

With all the news the past week, I have not had time to study what a transition to Slackware 64-bit would mean to me. I have a 64-bit machine (AM2), but I have three 32-bit machines I maintain for tinkering and testing. I also run virtual machines with VirtualBox.

I would want to continue compiling 32-bit packages for my 32-bit machines, but I don't want to compile them on those slow machines. From what I have read to date, I likely would have to maintain parallel operating systems on my 64-bit machine: Slackware (64-bit) and Slackware (32-bit). I'd have to reboot into the 32-bit OS to compile 32-bit packages. Or maintain a virtual image of the 32-bit machine.

Then there is the issue of KDE. In my opinion, KDE 4.x is not yet complete for my usage because several third-party apps are not ready. To convert to 64-bit would mean compiling the entire 3.5.10 desktop. Yet I'll guess that 3.5.10 would break on a 64-bit OS. I'm not adverse to converting to KDE 4.x, I just want to do so when all of the third party apps I use are 4.x compliant.

I also have not yet read that a 64-bit OS is dramatically faster than 32-bit. I get the feeling that outside of compiling software, us "typical" desktop users will see no noticeable gain in speed. I'd like to read more because I remember the transition from 16-bit to 32-bit. That was in the Windows world, but 16-bit was faster than 32-bit in certain ways. I wonder if the same will happen with the transition from 32-bit to 64-bit.

I suppose then I'll be running 32-bit Slackware for a while.

Woodsman, compiling KDE 3.5.10 for 64-bit shouldn't be a problem-I'm currently running it in Slamd64.

Pat should decide if he has time to maintain the compatibility layer. You wouldn't want that he stopped releasing patches and focused his attention on the compatibility layer. But in time, I suppose, it might come in extra.

Well, technically it doesn't really matter, because even if it doesn't have it, you could just use a chroot with slackware packages right ?

So, although I voted yes, I meant it in the way that there would be some way to run 32-bit libs, it doesn't have to be a /usr/lib compatibility packages, it can be a chroot.

Arny seems to have posted a way to do it on bw64, which may work here:
http://www.bluewhite64.com/e107_plug...wtopic.php?565

Why should Pat be forced to maintain the compatibility layer? That is something which could be easily turned over to the community, just like GNOME was.


I myself just don't know at this point if I need 32-bit compatibility or not. I am waiting for the stable 64-bit release so I can finally try out a 64-bit Slackware on my notebook. If all the essentials are already 64-bit, and I don't see myself running into issues, I may just keep the 64-bit Slack, and leave the 32-bit to my ancient desktop that is still clinging on to dear life, remarkably well I might add.

I think in the long run however it would be best just to forge on ahead as 64-bit only though, otherwise there will always be this 'transitioning into 64-bit.' If the sources are out for at least 99% of the software (1% excluding binary only like flash, etc), then I see no point keeping around 32-bit compatibility. Drivers are also provided in 64-bit as well.