Hi,

The team made 'Slackware64® -current' a pure 64. Get the point! If a user wants to have 32-bit support it will be up to that 'individual' to accomplish the task. Fortunately the team provided for future expansion. This is 'Slackware64® -current'. You should allow things to develop as it should for this testing. Maybe 'Slackware64®' will be released as multilib but why should they if a user(individual) has Slackware® to use on their 32bit system. I for one understand the reasoning behind the use of 32bit and 64bit for each OS. Slackware64® hopefully will stable after a good testing session and thus maturing to another great release.

Posting a link as a defense of one's argument without comment shows the weakness of the original argument.

Hi,
I think the weighting of a THUMBS nwod would be great. But I believe a user should be awarded the icon therefore you won't constantly see the 'Thanks' or 'THUMBS nwod' within a post.

I agree with Dinithion about not feeding the troll, but, unfortunately some trolls won't go away even if they're not fed. And Shingoshi seems to be one of them.

This is great. I was waiting for the official 64 build

I saw the news on slackware.com and came here to get others' opinions and guess what I find, a few days old post at 16 pages Too bad it's mainly troll excrement

Shingoshi opened another thread on upgrading Slack to Slack64. I wish he had done that much earlier, the information there will certainly be useful for some of us and they can continue there. It's absolutely fine to discuss various upgrade scenarios for those interested but no one has the right to blame the developers about things they don't have to do.

Anyway, hoping this is all over, I want to say a second "hooray!" for the wonderful news about Slack 64 .

Although I do not have any need at this moment for a 64-bit installation, I'm playing with it out of interest.

My 32-bit Slackware performs very well on my machines, even with >4GB (using my own custom kernel).

But I understand 64-bit is the future, as we have seen the change from 8 to 16 and 16 to 32-bits.
I do not use any program that needs 32-bit support I think (no use for Wine) and have no problem at all with compiling from source if needed.

I guess I will use dual-booting for a while between Slackware & Slackware64, until I am 100% comfortable with Slackware64.

Any idea how the subscription service of Slackware will work when Slackware64 13.0 is released? I am presuming that both 32-bit and 64-bit versions will be released at the same time.
I might buy the DVD with the 64-bit version separately, just as a way to thank for all the work done by the team.

The only "complaint" i have with Slackware64, although i havent tried it yet, is that the package selection is identical to the one of the 32bit Slack.
I've said it before in another thread, that for example , Slamd64 doesnt include apmd. acpid has fully replaced it long ago, even in older machines.
AFAIK acpid is better and fully supported by 64bit hardware. On the contrary apmd isn't.
There are some applications that i would like being updated, or even better replaced by other ones or removed completely. I have some of them posted in the what features would you like to see in future Slackware thread. I think this is an opportunity to start from a (slightly) different ground. Now that backwards compatibility isnt an issue.
Does the 64bit port need to have exactly the same packages the 32bit one has?
I do realise that maintaining different kind of packages for each architecure will increase maintainance load.

First, I must say that I greatly appreciate the efforts of all those involved in bringing about a 64 bit Slackware and thank you all albeit I personally have no need for a Slack64 ATM.

Secondly, I just had a look through this thread over my morning coffee and was saddened to see a descent into useless quibbling over issues of little or no constructive purpose by some parties.
Thank you Robbie, it is unfortunate that observations such as the above very seldom get aired publicly on this or any other list. Perhaps their are those who constantly clamour for this or that among the greater body of open source users who should temper their demands and opinions with due consideration that they are getting a great deal of innovation, software, and support for most probably nothing.

I was actually quite surprised to see it appear in Slackware 64 - we made a conscious decision with Slamd64 not to port that package (plus the fact that I think there are few, if any, AMD64 systems that work properly if you disable ACPI, and I doubt any of those use APM as a fallback anyway).

Indeed - it's far better to keep the two in sync as much as possible (give or take packages that don't make sense on x86-64 - e.g. loadlin, isapnpntools). We had more than enough trouble in Slamd64 on the few occasions where we were forced to diverge from Slackware, so I don't recommend any such divergence. So I suspect Slackware will keep the same packages for both x86 and x86-64; after all, it wouldn't be Slackware otherwise

There's another advantage to the 64bit release which is not that obvious... One of the things I've disliked about Slackware in the past is the fact that not every package is rebuilt with every release. In some cases the origins of some packages have dated back several releases, and the build in the source tree has not even built under that release. Owing to the necessity to recompile everything for 64bit, the upcoming Slackware64 release will probably be the most internally consistent we've had for a long time and this is why I'm thinking of switching to it when it releases rather than for any need for a >3G application address-space.

Very keen observation GazL.

I've been advised by the SlackStore that the 64bit DVD will be dual sided and have both 64 and 32 bit versions on it
I am revising my subscription to that DVD

john

I was wondering about that. I will probably do the same.

That's a steal

That's great, congrats Slackware team