64 bit Slackware?

Hi there
Does anybody know a 64 bit slackware without lots of bugs especially if it needs to run a 32 bit application.
I dont really know if this is true but logically a 64bit operating should be able to run a 32bit application while the opposite should not be possible.
Any ideas?

Thanks
Manos

Well note that you can't run, at least all, 16-bit apps inside a 32-bit Windows so it's not at least always possible. I know a lot of small 16-bit old programs that don't run on XP, for example and I bet it's not just Microsoft.

But to the original question: no, I haven't heard. But maybe you could compile stuff and create one of your own?

Slamd64 is supposed to be an unoffical 64-bit port of Slackware, you might want to check that out, as for running 32 bit programs under it, you should be able to run it just fine I think.

There are ways to run 32-bin programs on a 64-bit OS, but it doesn't always work right. You have to use a number of workarounds. Why do you need to run 32-bin applications anyway ? You don't have 64-bit versions of them ?

Some applications are not 64 bit clean, or rely on 32bit x86 assembly so cannot be easily ported (or occasionally the odd binary here and there which needs to be run).

In which case, and from personal experience, Slamd64 will fit the bill, as it's a true multlib x86_64 Slackware port (i.e. no need for 32 bit chroots just to _run_ a 32 bit application).

http://www.bluewhite64.com/
http://www.sflack.com/
too.

Originally Posted by H_TeXMeX_H There are ways to run 32-bin programs on a 64-bit OS, but it doesn't always work right. You have to use a number of workarounds. Why do you need to run 32-bin applications anyway ? You don't have 64-bit versions of them ?

Of couse not all applications work. I think OpenOffice.org could be a big showstopper for many people. At least me I'm relying heavily on it to do my work and there is still no fully working port for x86_64. Building from source is usually not that difficult for me, but looking at the OOo stuff I'm getting scary So I think while most apps compile fine on that (at least when I tried) besides mplayer codecs and flash OpenOffice is a must have that is available only for 32bit.

Originally Posted by Alien_Hominid http://www.bluewhite64.com/ http://www.sflack.com/ too.

Neither of those are multilib, so they cannot run any 32 bit applications without installing a full Slackware chroot; and there are also other ethical reasons for why I _cannot_ recommend anyone to use BlueWhite64.

Originally Posted by cathectic ... and there are also other ethical reasons for why I _cannot_ recommend anyone to use BlueWhite64.

Would you mind going a little bit into detail here? I'm interested in this, took a closer look at the 64bit systems some days ago myself, so this info could be important for my decision between slamd64 and bluewhite64.Maybe it's something others know but

I think OpenOffice.org could be a big showstopper for many people.

I don't think so =)

http://ftp.linux.cz/pub/localization.../680/2.2.0-RC4

administrator@melchior:~$ file /opt/openoffice.org2.2/program/soffice.bin 
/opt/openoffice.org2.2/program/soffice.bin: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), dynamically linked (uses shared libs), stripped

I think reading the slamd64 forums at http://forums.slamd64.com will give you the answer to your last question, too.

I will second the notion that slamd64 is what you're looking for - multilib is most definitly *the way* when it comes to x86_64, because it's running x86 instructions natively not emulatiing them. The whole architecture was designed to run 32-bit binaries to make compatibility easier to make the switch easier.

Use it and be happy =)

95% of the problems you'll have with using Slamd64 will be slackware-solvable (that is things like forgetting ZAxisMapping or not running the mysql install scripts), you'll find a fair few other problems (I say problems, I mean "gotchas") when you start compiling, and even *more* gotchas when you start wanting to compile 32-bit binaries, but there are many on here who can help if it's not already been answered on the slamd64 forums (see above).

- Piete.

Ok. Found it at: http://slackadelic.com/2006/09/22/i-...ke-it-anymore/

Personally, I think it's silly war, because everything is GPL'ed and still 90% of pc's are windows. There are better ways to concentrate on and the power is in unity. I might be wrong cause I don't have 64 bit pc so I know only what I have read about.

Originally Posted by piete I don't think so =) http://ftp.linux.cz/pub/localization.../680/2.2.0-RC4

Thanks, I found a link in the forum when I had slamd64 installed to test it (maybe two months ago), but at that time the link was dead, so no English oder German version was available. I would like to see an official 64bit port though and hope it's just a matter of time that this will be available in near future.

I think reading the slamd64 forums at http://forums.slamd64.com will give you the answer to your last question, too.

Sounds, ehm, at least interesting. I think "forking" per se is ok, but deleting the post without allowing a discussion on a post isn't. The one (and only) thing that attracted me about bluewhite64 is that it seems to follow Slackware current quite in time while slamd64 seems slower with this. Anyway I was impressed with slamd64 so far, I guess I will reinstall it the next days and see if I get the openoffice package working.

titopoquito

I use the OOo packages at sotirov.

They maintain the package fairly updated. This one is the Bulgarian
version but they say at the install text script that Bulgarian language
has to be installed separately. Default is english

-W

Originally Posted by Alien_Hominid Ok. Found it at: http://slackadelic.com/2006/09/22/i-...ke-it-anymore/

It actually goes slightly deeper than that. This isn't a GPL dispute - this is a dispute over credit where credit is due.

The fact is that that the BlueWhite64 developer asked, and received help, to ostensibly create a "Slamd64 Live CD" from the Slamd64 creator (Fred Emmott, who had put in the hard work to port Slackware to x86_64 in the first place - not a small, trivial job). This was then thrown back in Fred's face when the BlueWhite64 'creator' posted his own x86_64 distro, submitted various articles about it, and claiming that _he alone_ had single-handedly ported Slackware straight to x86_64, without help (there is the odd fleeting reference to Fred, left over from the directly copied bits, but that's it; denial over everything else).

While it is legal to do so, it is completely and utterly unethical. (I mean, let's say I created my own distribution, based on Slackware and its' glibc and gcc; then claimed I had single handedly done all the work to create it and maintain it in the first place - what do you think people would think of me in that case? Would you use such a distribution? I _don't_ want a person like that responsible for the distribution that goes onto my machines.)

As piete has already mentioned, this is covered further on the Slamd64 forums - I don't really want to clog up LQ.org with this.

Originally Posted by titopoquito it seems to follow Slackware current quite in time while slamd64 seems slower with this

While Slamd64 appears slightly "slower" on updates, please be aware that Fred Emmott (Slamd64 creator/ maintainer) actually tests the updates first on his own system, before posting them - unlike what others do, one cannot just blindly copy over all Slackware's changes to a different architecture without testing them first (Pat certainly doesn't just post Slackware updates without testing them first), as there are other bugs that can creep up on x86_64 that may not appear on i386/ x86.

Of course, if you want guaranteed security updates (e.g. for running a mission-critical server), then there is no substitute for running Slackware itself in such a situation.

Originally Posted by cathectic It actually goes slightly deeper than that. This isn't a GPL dispute - this is a dispute over credit where credit is due. [...]

Thanks for clearing that up.

While Slamd64 appears slightly "slower" on updates, please be aware that Fred Emmott (Slamd64 creator/ maintainer) actually tests the updates first on his own system, before posting them - unlike what others do, one cannot just blindly copy over all Slackware's changes to a different architecture without testing them first (Pat certainly doesn't just post Slackware updates without testing them first), as there are other bugs that can creep up on x86_64 that may not appear on i386/ x86.

I shouldn't have deleted the already written sentence about stability. The slower pace is absolutely ok for me if it works when installed. And slamd64 worked very very well when I tested it.

Originally Posted by mokele I use the OOo packages at sotirov. They maintain the package fairly updated. This one is the Bulgarian version but they say at the install text script that Bulgarian language has to be installed separately. Default is english

Thanks a lot. I'll grab (hehe, just wandered if it is written "grep") a copy of OOo 64 bit and slamd64 later this evening.