SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Wow, incredible ! This is astounding news ! Thank you very much to all the Slackware maintainers especially Alien Bob (Eric), I think you made a very good decision. I'll be trying it as soon as I can.
How come I didn't hear about this before tho ?
We've been developing and testing Slackware64 for quite a while. Most of the team is already using Slackware64 on their personal machines, and things are working well enough that it is time to let the community check our work.
it was kept secret ?
Last edited by H_TeXMeX_H; 05-20-2009 at 04:36 AM.
Of course I *will* try it out on one of my test machines - I have a 30GB partition left for this.
But it will be just for testing for now, until we have some idea about compatibility with non-Slackware software.
How about Slackbuilds - will they build on Slackware64?
Any chance of marking them as "works on Slackware64"?
Anyone already installed it and did some benchmarking?
Take a look at the newer SlackBuilds.org template. Many already follow this template, or something close to it. Those that don't you can edit by hand. You'd have to change the arch for each SlackBuild for i486 to x86_64 anyways
Slackware64 is just like most 64bit distros. Slightly larger binaries, slightly larger RAM footprint, 10-30% speed up with multimedia apps that use 64bit code. The slightly larger footprint is just that - slightly - gimp-2.6.6-i486-1.txz 9.0 MB gimp-2.6.6-x86_64-1.txz 9.4 MB.
Normal desktop users won't notice much more than the psychosomatic speed gain. The speed comes from applications that can take advantage of SSE, SSE2 and other ASM optimizations. Mainly your multimedia encoding applications, Blender, POV Ray, CAD, and other big number crunchers. Some GCC compile times should be less as well. Compiling MPlayer, and Seamonkey seemed to take less time on 64bit, but I did not time it. Maybe later I will.
Another solid point for 64bit is the capability to handle large data arrays. Besides the normal server stuff (Mysql), even Pan is getting to the point of surpassing the capability of 32bit address space with large newsgroups. Some news providers carry 200-300 days of current binary retention, and over 1000 days text retention.
As far as negatives, if you depend on Wine, Wine64 is not currently stable, this would also include Google's apps that are just encased in a Wine wrapper (Google Earth, Picasa). Win32codecs for mplayer use 32bit Windows dll files. With a multi lib system you can run these in 32bit user space.
At least we now have 64bit Flash, and better 64bit JRE.
You have no idea how hard that was with some of the discussions that went on here
I can imagine, either way I wasn't very aware of it at all. There were some hints like stated above, but I thought they did that just to provide better support for the other 64-bit slackware-based distros, not for a secret slackware64. So, it worked quite well I think.
This is excelent news, released just in time. I currently don't have the hardware to test it, but I'll code support for the 64-bit variant in slackroll as soon as I get home and receive some confirmations on how the tree is supposed to work.
Congratulations to the Slackware team and Eric Hameleers in particular!
I'm very excited over this, I've been wanting to use Slackware again for a long time. Funny thing is, I just downloaded Slackware 32-bit & Slamd64 to try them out again. Now, I'm downloading the iso for Slackware 64 that someone put up on linuxtracker.org
Last edited by Riser Glen; 05-20-2009 at 09:03 AM.