Slackware 64 Released!
+Alan Hicks+
Hash: SHA1
Yes, it's finally happened. Slackware has gone 64-bits. Things should
be farmed out to your favorite mirrors soon. Look for it in...
/pub/slackware/slackware64-current
One of the first mirrors to have this will be cardinal.lizella.net.
Enjoy.
- From the ChangeLog...
========================================================================
Tue May 19 15:36:49 CDT 2009
<tick> <tick> Ermm... is this thing on?
Initial public release of Slackware64-current.
He's trying to lay low, but thanks to Eric Hameleers for the huge amount
of work he did to make this possible. :-)
Enjoy!
- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkoTP2YACgkQNj1TaGS9H5I9qgCghfiHw/TIufzMljqpHgutLLa4
DRkAnjiDTEQjUQM8WwTFIJZjRPE690EO
=JAPg
-----END PGP SIGNATURE-----
Auric__
> Yes, it's finally happened. Slackware has gone 64-bits. Things should
> be farmed out to your favorite mirrors soon. Look for it in...
>
> /pub/slackware/slackware64-current
>
> One of the first mirrors to have this will be cardinal.lizella.net.
> Enjoy.
>
> - From the ChangeLog...
>
> ========================================================================
> Tue May 19 15:36:49 CDT 2009
> <tick> <tick> Ermm... is this thing on?
>
> Initial public release of Slackware64-current.
> He's trying to lay low, but thanks to Eric Hameleers for the huge amount
> of work he did to make this possible. :-)
So how does this relate to Slamd64? At all?
--
I'm as decadent as the city I infest; it's my natural element.
Martin Schmitz
> So how does this relate to Slamd64? At all?
>
lot of "Thanks to Fred Emmott". ;-)
Martin
andrew
> Initial public release of Slackware64-current.
Huge news! Should make Slackware 13 one of the biggest releases ever?
Andrew
--
Do you think that's air you're breathing?
Grant
...
>Yes, it's finally happened. Slackware has gone 64-bits. Things should
>be farmed out to your favorite mirrors soon. Look for it in...
>
> /pub/slackware/slackware64-current
This is good, wonderful, great! What of Fred?
How big's the install tree?
Grant.
--
http://bugsplatter.id.au
Res
Res
-Beware of programmers who carry screwdrivers
Joseph H. Rosevear
> On 2009-05-19, +Alan Hicks+ <al...@lizella.netWORK> wrote:
> > Initial public release of Slackware64-current.
> Huge news! Should make Slackware 13 one of the biggest releases ever?
Andrew,
Thanks for mentioning Slackware 13. That's where this is going, right?
Sort of a "do or die" "don't look back" "you're with us or you're
against us" thing?
I'm immediately wondering whether it will be good for *me*. What will
I need to do to adjust? Will I need new hardware?
> Andrew
-Joe
Michael Black
> andrew <and...@skamandros.invalid> wrote:
>> On 2009-05-19, +Alan Hicks+ <al...@lizella.netWORK> wrote:
>
>>> Initial public release of Slackware64-current.
>
>> Huge news! Should make Slackware 13 one of the biggest releases ever?
>
> Andrew,
>
> Thanks for mentioning Slackware 13. That's where this is going, right?
> Sort of a "do or die" "don't look back" "you're with us or you're
> against us" thing?
>
What's the question?
The next release of Slackware has been worked on since Slackware 12.2
was released back in December. What number the next release carries
will end up being revealed when it is released.
This 64bit version of Slackware is merely being done in parallel with
"original Slackware". It's in addition to, not a replacement for.
Michael
Eric Hameleers
A lot? Only four that I can think of (glibc ash minicom and inetd).
Neither slamd or bluewhite64 were used as a basis for slackware64...
Eric
Simon Sibbez
Some people are disabled and only got one hand by now. So four is
actually "A lot" in their frame of reference.
Diving for the hard deck,
S.
Peter Chant
Joseph H. Rosevear
[snip]
> The next release of Slackware has been worked on since Slackware 12.2
> was released back in December. What number the next release carries
> will end up being revealed when it is released.
> This 64bit version of Slackware is merely being done in parallel with
> "original Slackware". It's in addition to, not a replacement for.
Ah. I didn't know that.
Still, I'm interested to learn more about the 64bit version.
> Michael
-Joe
Keith Keller
>
> Still, I'm interested to learn more about the 64bit version.
What, specifically? The only real difference is that the binaries and
libraries have been built by a 64-bit compiler, so a) they won't run on
a 32 bit processor, and b) they will be faster (to varying degrees) than
32 bit programs on a 64 bit processor.
Depending on how it was built, there may be 32-bit compatible libraries,
for situations where a 32-bit binary is distributed without source or a
64-bit version. This used to be quite important; I suspect that most
vendors who choose not to distribute source code now build for both x86
and x86_64 platforms, so it's less important now. Still, you might want
to look at what programs you use (mainly proprietary ones) before
getting 64-bit hardware and software. (You can still run 32-bit
Slackware on 64-bit hardware, so you could buy the hardware and, if an
important program didn't run in Slackware64, go back to Slackware.)
That's about it. The differences are certainly less than, say, the
difference between an x86 distribution and a PPC distro.
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
Peter Chant
> Depending on how it was built, there may be 32-bit compatible libraries,
> for situations where a 32-bit binary is distributed without source or a
> 64-bit version. This used to be quite important; I suspect that most
Slamd64 in my limited experience does that really well. No problem with
standard 32 bit packages on that system.
Peter Chant
>
> -Beware of programmers who carry screwdrivers
What do you do if you see one with a soldering iron?
Pete
Auric__
> Res wrote:
>
>> -Beware of programmers who carry screwdrivers
>
> What do you do if you see one with a soldering iron?
You'll need an old priest and a young priest...
--
Children! Consume your siblings!
~kurt
>
> The next release of Slackware has been worked on since Slackware 12.2
> was released back in December. What number the next release carries
> will end up being revealed when it is released.
According to the latest news on <http://www.slackware.com/>, it will be
13:
"DVDs will be available for purchase from the Slackware store when
Slackware 13.0 is released."
- Kurt
Res
> Res wrote:
>
>>
>> -Beware of programmers who carry screwdrivers
>
> What do you do if you see one with a soldering iron?
>
threaten to turn off the database servers and change the location of
things like perl and python :)
--
Res
Res
> "DVDs will be available for purchase from the Slackware store when
> Slackware 13.0 is released."
so when the superstitous for some release appears, i'll be able
to get rid of the superspurious centos 64 on the 64bit boxens
Keith Keller
>
> threaten to turn off the database servers and change the location of
> things like perl and python :)
Or just swap 'em!
# mv /usr/bin/perl /root/oldperl
# mv /usr/bin/python /usr/bin/perl
# mv /root/oldperl /usr/bin/python
Instant chaos!
Michael Black
> On Wed, 20 May 2009, ~kurt wrote:
>
>> "DVDs will be available for purchase from the Slackware store when
>> Slackware 13.0 is released."
>
> so when the superstitous for some release appears, i'll be able to get rid of
> the superspurious centos 64 on the 64bit boxens
>
I thought the original post was going to tell us Slackware had jumped
from 12.2 to 64.0
Michael
Mark Madsen
> Yes, it's finally happened. Slackware has gone 64-bits.
Hell, is it the 21st century already? Why wasn't I told?
King Beowulf
I've been running both Slackware on my 32 bit systems (mainly old laptops) and SLAMD64 on my
AMD64 systems since its initial release. It was the only Slackware derived distro that stayed close to
the Slackware ideals. Most Slackware 32-bit packages run just fine for the most part (need to keep
an eye on 32 bit lib dependencies) and also those programs that are not 64 bit clean and need to be
32 bit compiled. Most/all slackbuilds.org and builds.slamd64.org build scripts are interchangeable
with minor adjustments (such as for lib64) and I have a lot of unified slackbuilds i use for both arch. I
hear that 32 bit compatiblity in Slackware64 will also be available and as good. I may be wrong, but
a lot of Slackware users seem make up the SLAMD64 user base, if forum posts are anything to go by.
Anyway, I look forward to a comparison. I've already cleared off a 20GB partition...
--
"In questions of science the authority of a thousand is not worth the humble reasoning of a single
individual." --Galileo Galilei
Loki Harfagr
> On Tue, 19 May 2009 23:23:19 +0000, +Alan Hicks+ wrote:
>
>> Yes, it's finally happened. Slackware has gone 64-bits.
>
> Hell, is it the 21st century already? Why wasn't I told?
/sloanequote
Dirk van Deun
: be farmed out to your favorite mirrors soon. Look for it in...
I have never tried to upgrade a 32-bit to a 64-bit system without wiping
the whole disk (well, except /home) and starting from scratch. Is it
practical to upgrade without wiping everything for going from slackware
12.2 to slackware64 current ? If so, in what order should one add
and replace components never to end up in a completely unusable
intermediate state ?
Dirk van Deun
--
Ceterum censeo Redmond delendum
Grant
I'd expect an unusable state, start with a clean partition, it's going
to work first time for you. The cherry-pick .conf files from the old
slack-12.2 install to customise?
I've just installed 12.34567890 and it's great, just like slackware :o)
CLI only, so far, to get multi-boot properly going -- trivial, just like
slackware. Odd, that.
Only surprise was Tuz on bootup screen instead of Tux, but Tux is back
from the next kernel release (2.6.30).
But yes, back to windoze on this box again -- I'm in-betweener state,
haven't setup the slack desktop yet.
Grant.
--
http://bugsplatter.id.au
Mark Madsen
> Mark Madsen wrote:
>
>> Hell, is it the 21st century already? Why wasn't I told?
>
> If you were happy, did you really need to know?
</modquote>
Mark Madsen
:-)
Eef Hartman
> What, specifically? The only real difference is that the binaries and
> libraries have been built by a 64-bit compiler, so a) they won't run on
> a 32 bit processor, and b) they will be faster (to varying degrees) than
> 32 bit programs on a 64 bit processor.
Not always. In fact sometimes they will be SLOWER (as the executable
is larger and memory references (64-bit pointers) are twice as large).
But they will be able to control more memory (RAM) so on machines with
more memory then, say, 3 GB a 64-bit version is quite usefull.
--
*******************************************************************
** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
** e-mail: E.J.M....@tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
*******************************************************************
~kurt
>
> Not always. In fact sometimes they will be SLOWER (as the executable
> is larger and memory references (64-bit pointers) are twice as large).
I imagine it should help out with scientific number crunching that is
constantly moving 64 bit doubles around. I had done an experiement with
C some time back comparing 32-bit floats to 64-bit doubles. I was
surprised to see the standard 64-bit doubles were handled about twice as
fast on my 32-bit system. I'm guessing it is some compiler
optimization. I think I had read all floating points were handled
internally as doubles, so there had to be some conversion back to floats
that probably slowed things down.
- Kurt
Keith Keller
> Keith Keller <kkeller...@wombat.san-francisco.ca.us> wrote:
>> What, specifically? The only real difference is that the binaries and
>> libraries have been built by a 64-bit compiler, so a) they won't run on
>> a 32 bit processor, and b) they will be faster (to varying degrees) than
>> 32 bit programs on a 64 bit processor.
>
> Not always. In fact sometimes they will be SLOWER (as the executable
> is larger and memory references (64-bit pointers) are twice as large).
Well, slower is a varying degree of faster. ;-) Thanks for the
clarification, though.