Slashdot Mirror
64-Bit Slackware Is Alive
t0mg writes with this news from the top of Slackware.org "from the Slackware64-current changelog: [tap tap tap]... Is this thing on? ;-) Ready or not, Slackware has now gone 64-bit with an official x86_64 port being maintained in-sync with the regular x86 -current branch. DVDs will be available for purchase from the Slackware store when Slackware 13.0 is released. Many thanks go out to the Slackware team for their help with this branch and a special thank you to Eric Hameleers who did the real heavy lifting re-compiling everything for this architecture, testing, re-testing, and staying in-sync with -current. 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. We'd like to thank the unofficial 64 bit projects for taking up the slack for us for so long so that we could take our time getting everything just right. Without those alternatives, we would have been pressured to get things out before they were really ready."
http://www.slackware.com/announce/1.0.php
http://ebgp.net/ccc/
Yeah, unless it's Ubuntu which needs fixing. Slackware is being very conservative, and it's core system hasn't changed a lot in recent years - which is much different from Ubuntu or Fedora. Things like booting process, sound subsystem or package management are totally different now.
I loved slackware but got sick and tired of compiling everything myself... and switched to gentoo where ebuilds were. Then switched to OpenSuse... and finally I am Ubuntu user, quite happy one (not too but still).
Most of the team is already using Slackware64 on their personal machines, and things are working well enough
From personal experience "well enough" for the Slackware folks is far beyond anything others consider "fabulous."
Point 1 - I don't know how much room is on the DVD, so I can't speak to that. Slackware packages only take up 4 CD's though, the last two are source. A SlackBuild script for i386 and x86_64 could be provided with all the source still fitting on 2 CD's. You would probably then have to add 2 more CD's to hold the rest as I don't believe the rest of disks were full, I believe CD 5 or 6 is just KDE. The current filesystem layout that existed since Slackware 3's floppies might need to be revamped to make more efficient use of space though.
Point 2 - Slackware upgrades are braindead simple and are indeed supported. UPGRADE.TXT always details how. As upgradepkg is simply remove the old package and install the new one (while being intellegent with config files) I don't see why you couldn't simply remove the old i386 packages and replace them with x86_84 ones. In a perfect world anyway.
Point 3 - I have used Slackware for a bit and I know the release cycle. I can however still wonder.
"I use a Mac because I'm just better than you are."
Additionally, Slamd64 isn't AMD-only at all. slamd64.com runs on an Athlon64 X2, but it developed on my desktop with a core 2 quad, and my laptop with a core 2 duo.
That should be expected, on a modern Intel P4 or Pentium D. The AMD64 architecture is a bit of a misnomer, nowadays. The original Intel Itanium 64-bit, IA-64 architecture, did not support backwards compatibility with the x86 architecture. The first AMD Athlon 64-bit chips, on the other hand, fully supported x86 architecture.
It did not take long for Intel to see the error of its ways. Intel came up with their own implementation to be compatible with AMD64 architecture and Intel markets it as EM64T. In a nutshell, the true AMD64 architecture on a 64-bit Athlon is compatible with a true EM64T architecture on a 64-bit P4/Pentium D/Xeon. However AMD64 architecture is NOT compatible with the original Itanium IA-64 architecture, so any chips marketed as Intel Itanium, or earlier Xeon models, will not have the proper 32-bit extensions for AMD64 compatibility. All of these x86_64 incompatible Intel chips are probably 5 years or older now.
The more common name I have observed is AMD64, especially when it comes to Linux packaging. My kernel reports x86_64 with uname though, so the inconsistencies might be confusing to some. But x86_64 is really just a vendor neutral way of labeling two different vendor implementations of the same architecture. I suppose there is good reason to still call it AMD64, since they were, in fact, the first vendor to introduce the technology.
AMD64 == x86_64
EM64T == x86_64
(Itanium || IA-64) != x86_64
/^([Ss]ame [Bb]at (time, |channel.)){2}$/