64-Bit Slackware Is Alive 164
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."
Re:Glad to here. (Score:3, Interesting)
Slackware is a beautiful server distro, but I used to use it as my primary desktop distro until comparatively recently. The only reason why I stopped was because of a long hiatus in the maintenance of the Dropline Gnome distribution. I just don't have time to build all that stuff myself, and it used to be so good. (And no, Gentoo just does not fill that gap.) Now I am mostly using Arch Linux [archlinux.org] which is similar in the important ways to Slackware (sweet!) but with the advantage of more current package builds.
Re:Just now? (Score:2, Interesting)
The amount of memory an OS or architecture can support is rather meaningless if the maximum amount of addressable memory of a process is still too small. Even with PAE a process can only fit inside of 32bit memory space.
It's incredibly easy these days to get a single process over 3GB of memory allocated, which is the largest process size on a 32bit linux. The only way around that is with hugepages, shared memory or other creative memory assignments.
Try working on data sets larger than your personal address book and it's easy to break the 32bit barrier.
Re:+1 on Arch (Score:2, Interesting)
I wasn't particularly clear, but these were cases where the ebuild wasn't checking for USE flags before enabling an optional feature at configure time. Inkscape and numpy was one example, one where I began building inkscape manually. Yeah, I'm stubborn but I did things this way for years when I was a slackware user. Speaking of which, when I first started using gentoo it was perfectly simple to set up a system without PAM, it became so much jumping through hoops that I eventually gave in. Long live choice eh?
That's the idea isn't it, that the user can prevent optional stuff from being fetched and built? If ebuilds are not going to let me keep dependency bloat to a minimum, why then would I continue to use gentoo? There's little to gain from compiler flags on my first generation AMD64 boxes; Possibly on my newer intel machines but it's not going to make a huge difference. The Arch ports style tree (abs) is perfectly usable, PKGBUILD's are much easier to write than ebuilds and (although I initially found it difficult after using emerge for so long) pacman is a pleasure to use. That was my point ;)
Slackware was a great distro and retains it's place in heart if not on my machines, I strongly considered going back to Slackware before I found Arch. Gentoo: mask or unmask this, unmerge that to resolve a packaging conflict, run revdep-rebuild, no USE flags to disable stuff I don't want or need, perform a dance with a rubber chicken while you recompile half your system, eselect this, eselect that... I'm not missing Gentoo at all although it'd still be my personal preference over debian and RH based distros.