After Current is official I'm considering 64-bit. I have the hardware on my primary machine. Frankly, I'm way behind in the knowledge base about running both types of systems. Been browsing the forum trying to wrap my head around some of this....

I also have 32-bit machines to maintain.

If I understand correctly, if I use a 64-bit OS, I can compile software for 32-bit machines --- but I need to install multi-lib support, add appropriate options in the build scripts, and change environment variables. Seems complicated and potentially a hassle (I'm getting older and lazier ). Would a 32-bit chroot or virtual machine be more straightforward to build packages for 32-bit machines?

Is there a list somewhere of known apps that have no 64-bit version?

Seems that games are the biggest challengers, but I don't play any third-party, non-stock, or online games.

I don't use WINE or Skype.

I use the flash plugin, VirtualBox, and the proprietary nvidia package (I plan to play some with the nouveau driver).

Comments appreciated.

Thanks.

Hi

I am a total noob to Slackware but have 13.1 32 bit on my netbook and 64 bit 13.37 on my thinkpad.

In terms of 32 bit problems I have only noticed one broken package so far and that is rtorrent.

Virtualbox I downloaded the 64 bit pre-compiled binary from Oracle and can now run 64 bit guests. All other major software is ok, claws, firefox, dropbox, libreoffice.

The only major bit of tweaking I had to do was the thinkpad fan daemon tpfand and tpfan-admin. Here I had to hack the makefile to point at different python version in lib64 and have to remove references to rsvg, which removed a fan svg icon and all was good again.

The only ones I have yet to face are Wine for spotify and Inkscape, rtorrent will be my first attempt at getting a 32bit running.

For me having 64 bit is worth it, just to be able to run 64 bit OS guests in Virtualbox.

I switched to 64-bit last summer and I haven't found anything particularly difficult or annoying. From your main list, Adobe Flash and NVIDIA drivers both have a 64-bit version, so they are a non-issue. In the case of NVIDIA, it's official, stable and in theory well supported. In the case of Adobe Flash, you have to use some kind of "beta" plugin, available from their site. I don't use VirtualBox so I can't comment on that, but it appears a 64-bit version is available on their site.

http://www.virtualbox.org/wiki/Linux_Downloads (notice the AMD64 builds).

As for the rest, running a 64-bit system is like running a 32-bit one. The apps are the same, they are running and you don't immediately notice if it's a 32-bit or a 64-bit system. This applies to most things you compile from source too. It's just that you have to use --libdir=/usr/lib64 instead of --libdir=/usr/lib to call ./configure in your SlackBuilds.

Not using WINE or precompiled third party applications gets rid of most of your worries.

1 members found this post helpful.

Unless you want to run both 32-bit and 64-bit programs on the same system at the same time, I don't see the point of installing and maintaining a multi-lib environment. It might make sense to run a virtual machine.

Thanks for the replies thus far.

Usage wise I would not expect anything like that. I just don't know that I have the energy to maintain a multi-lib enviroment to support 32-bit systems. Good to hear about flash, VB, and nvidia.

As far as building packages, I think all of the scripts at slackbuilds.org accomodate either environment on-the-fly, at least the ones I use.

From what I have been reading today, that seems the better route (or a chroot). I don't expect to run 32-bit apps. I just need to compile them to support 32-bit machines.

I run Slackware64 since it came out.

Some simple answers:
- only expect problems with pre-compiled binary blobs like Skype or Google-Earth, for which no 64-bit packages are available.
- Wine won't work (because it's for 32-bits Windows software)
- To compile packages for 32-bit Slackware, use a VM that you can "freeze" to a snapshot, so that you always start from a clean building environment. This is also true for 64-bit packages, btw...

Good idea. Thanks!

Hi. FWIW

http://www.linuxquestions.org/questi...3/#post4254739

And, BTW, I ultimately didn't "know" it was 64 bit that made the difference -- it could have been a later or updated zip since the 32 bit in that case was on Slackware 12.2 and the 64 bit was Slackware 13.0

Nonetheless the 64 bit did that (zipsplit) job and it did it very well.

--
Alan.

I found that compiling 32bit software for other 32bit machines can be done in both a chroot environment and as a virtual machine. Personally, a virtual machine keeps things a little more contained... but then you have to deal with Virtual Box and various methods to install slackware on it either through a network share or mounted iso. Unless you use the "Host Interface" to do NFS, the HTTP and FTP methods are way too slow, especially over virtual machine.

But a chroot environment has its headaches as well.

The only thing that I've found troublesome on 64bit machines are things that use assembly code like zsnes. While it will run on a multilib 64bit machine, it will refuse to compile in your 64bit multilib environment.

Additionally, Virtual Box requires Alien Bob's Multilib packages. If you are using that anyway then other than dumb make files, you should be able to compile 32bit software that doesn't have 64bit support.

Which is correct?

The open source edition (OSE) of VirtualBox (like the one that gets compiled by the SlackBuild at slackbuilds.org) requires multilib to build (but I think not to run, though I may be mistaken here). The PUEL (closed-source) edition that you can grab from virtualbox.org does not need multilib (though obviously you can't make a neat Slackware package out of it).

1 members found this post helpful.

I've run multilib before, and wine runs just fine, as well as skype, and pretty much any other 32-bit program. I just don't need it anymore because I don't use any 32-bit only programs. Multilib can be messy, but if you're careful it won't be.

The only two applications I can think of (or that I actually would use might be better) are Adobe Reader and Google Earth that are 32-bit only (for now) and are not usable in Slackware 64-bit. I'm sure there are others. However, I do use VirtualBox on all my machines and both those applications work just fine in virtual machines. Everything else, all Slackware packages, OpenOffice.org (or LibreOffice.org when it stabilizes) are no problem whatsoever; I make use of some of the template packages and extensions for OpenOffice.org and they work as expected irrespective of the underlying platform (well, the ought to, eh?).

Other than that, one distinct advantage of 64-bit is that you can plug in as much RAM as you'd like (or that the motherboard can support) without having to recompile the kernel. If you run memory-intensive applications, that makes life a little easier.

An additional advantage that I find is that with compute-intensive applications 64-bit is (much) faster. One thing I do is generate maps using the Generic Mapping Tools (GMT) software along with really massive topological data (for surfaces). A 2-core, 3.2 GHz 32-bit box with 4G RAM running the same software and data completes a complex map at about 20% greater run-time than a 64-bit box with equivalent processor (actually the 64-bit is 3.0 GHz) speed and memory. Calculating maps is some heavy-duty mathematics and, in my experience, you get better performance with a 64-bit platform than with a 32-bit one.

Additional packages that I build either from SlackBuilds.org or using Src2Pkg (nice utility, that) build and run just fine on both 32- and 64-bit platforms so I'm a happy camper.

Too, 32-bit is going to go the way of 16-bit. Perhaps not next week but certainly over the next few years (and, of course, the next Big Thing will be 128-bit processors -- technology marches on).

Anyway, I'm happy with 64-bit and don't have any plans to look or go back.

Hope this helps some.

I may be one of the last still running 32-bit slackware on my main machines (I do run 64-bit on two servers). I'm hoping to move over when I can finally use 64-bit without needing multilib. I quite agree with Patrick's vision that 64-bit ought to be 64-bit (no 32-bit stuff around) and I am holding out until I can do it. At this stage it seems that the last block is skype, which I use heavily. The other possible one is the driver for an Epson scanner, though this may now have a 64-bit version as I have not checked recently and this is only for one of the desktops anyway.

I plan to investigate how well the switch goes when 13.37 is out, but I won't move my main desktops and laptops until there is a 64-bit skype.

I have been wondering about that. Are you saying I can't unzip the PUEL file and manually use makepkg to create a package? I don't like the idea of installing software that way. I use VB a lot and if I can't install as a package that might sway me toward 32-bit.

Adobe Reader...Google Earth...Skype...fortunately I don't use any of those but that is good info to know.