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,

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, :D , 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 :twocents: on the subject.
:D

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 :D

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. :scratch:

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.

I don't think so re: 32 bit...voted no....I tend to run Virtual Machines, actually, VB PUEL edition keeps me from booting into windows!

It would be nice if all programs played well with 64bits, however some just don't. If you have one or two of these programs that you have to use, and you do not wish to have to run two different systems, then you should probably answer yes.

If not then no would be a good choice.

Nobody is forcing the developers of our favourite system to do anything that they don't want to, I am sure that they look in from time to time and can make educated guesses as to what the system and it's users needs.

Please try to keep speculation and personal politics to a minimum, after all it is just a yes/no question :)

samac

no.

no.

Compatibility for migration
 

32-bit compatibility would make migration easier. However, I think I can swing it with with a separate 32-bit root, as opposed to a multilib setup in a common root. So I'd just need to have 32-bit compatibility turned on in the kernel (I build my own anyway). I'd just do a full install of 32-bit slackware in one directory tree, and 64-bit slackware in another directory tree, and pick which one to be root at boot time. This could be done via initramfs, initrd, or a patch I wrote for the kernel to allow choosing a subdirectory to be root on the parameter line.

By the looks of today's changelog, multilib will at least be possible in Slackware64. I don't expect the Slackware team to have to maintain the extra packages required for multilib, however I think it's nice that it will at least be possible.

Would be nice if one could just install (some) Slackware32 libraries into a Slackware64 system and end up with a multilib system (maybe with an optional multilib support package to set up for it). But I haven't used multilib, yet, so I don't know exactly what that requires.

I'd appreciate a multilib system but can live without, especially if going multilib makes everything (maintainance for the Slack team, compiling) much more complicated and if it brings weird behaviour.

From the Slackware64 -current ChangeLog.txt:
So it appears Fred is helping them out, and Slackware64 will have 32-bit support.
Maybe we can install 32-bit packages with some care, and they'll run, but perhaps
not be *officially supported* by Slackware.

Beowulf999 posted this in another thread.
samac

I don't know if I'm the only one, but I think a pure 64bit OS would be most desirable. It also fits our KISS principle.

I vote for Yes.

Primo: easier and quicker distro-upgrade from previous version of Slack.
Secundo: there are to many software not ready for 64-bit (ie. Wine, Skype, Sane)...

;)

Hi all,

Transitions in the computer world are a pain in the butt. I personally dislike setting up a new operating system, personalizing my settings, personalizing my wife's settings, etc. One of the things that I really like about Slackware is that, after I set it up, it basically runs unattended without problems -- except for applying the occasional security patch.

The important things for me are the applications. I need stuff to work and to work well. Slackware is an excellent distribution for adding lots of esoteric libraries to get even more esoteric programs to run (e.g. QGIS, GRASS, Wine, Scribus, Inkscape). If 32-bit compatibility is necessary for some of those programs, then I'm all for it.

I'm not saying that the full Slackware installation needs to have everything pre-installed, but I'd like to be able to use 32-bit libraries if I need them.

However, this may be a moot point. The above-quoted section from the --current changelog shows that 32-bit compatibility will be enabled.

Regards,

-Drew

I didn't voted because i wait to see if pure 64 is possible with all the stuff i use @home and @work...

In order to chroot and execute programs in a single script :

##########################
#!/bin/sh

cd /home/me/my_slack32_environment

chroot ./ <<EndChroot

/usr/bin/run_my_32bit_app

EndChroot
##########################

I vote Yes

certainly at least 5 years more

An operating system is to serve applications, not applications to serve operating system.

Hi,
No, a OS is to serve the user through the application(s).

Same. Same. The second is just another way of saying the same thing as the first.
:)

Create as optional? When (if) you need, download and install.

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.

Hi,
Each to his/her interpretation. :)

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?

my 2 cents

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.

samac

Hi,

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!

Hi Onebuck

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.

samac

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 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

Slack64 -- Finally :)
 

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 :D 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!

Sasha

Bump. :D