Voor mensen die aan Slackware Linux willen beginnen.

[Koen_92]

Hij is er in ieder geval druk mee bezig
Op dit moment zijn er nog wel een hoop stappen nodig om het werkende te krijgen (maar dat is voor iemand die Slackware gebruikt natuurlijk niet erg).

Ik ben benieuwd wat dit uiteindelijk zal worden.

[adri]

Slackware heeft de naam vrij conservatief te zijn (en dat klopt ook wel), vandaar dat het groot nieuws is dat Slackware sinds gisteren een heuse 64-bits versie heeft.
Er was al langer om gevraagd, maar nu is het dan zover (waar je en passant ook kunt lezen dat de volgende release van SW nr. 13 gaat worden -daar daar was wat speculatie over, schijnt iets met bijgelovigheid te maken te hebben ).

Door de liefhebbers wordt er druk over gediscuzeurd op het officieuze Slackware forum van LinuxQuestions.org.

Enjoy!

[Koen_92]

Dat werd eigenlijk wel een keertje tijd!
Alle grote distro's hadden namelijk al een 64bit versie, en Slackware hoort daar ook bij.
Verder bestond er al Slamd64, dus veel port-werk hadde ze zo over kunnen kopieren.

Maar ik ben toch blij dat er een 64bit versie is.

Zelf blijf ik voorlopig nog wel bij 32bit, omdat 64bit op dit moment eigenlijk geen voordelen biedt (tenzij je met multimedia aan de gang wilt).
32bit is op dit moment nog wel beter compatibel met alles (en dan doel ik vooral op de closed source programma' s)

[adri]

Voor een gewone desktopcomputer heeft het bar weinig voordelen.
Toch zal het stilaan wel die kant op gaan, schat ik zo.

[Koen_92]

Ja, het heeft echt weinig voordelen.
Voor die paar % dat het sneller is gooi je namelijk wel een hele hoop backwards-compatibility weg.

Op het Slax-forum kwam ik trouwens dit topic tegen:
http://www.slax.org/forum.php?action=vi ... ntID=38472

Daarin wordt er naast het feit dat er geen 64-bit is ook nog geklaagd over dat Slax voor i486 gecompileerd is ipv i686.
i686 is niet heel veel sneller, alleen niet compatibel met oudere hardware.
Ook hier heeft het weinig voordeel om voor i686 te gaan.

[adri]

Er staat ook de nodige onzin in hoor.

Wat betreft i486 vs. i686: knap als je de verschillen merkt.
Probeer anders Gentoo. Daar wordt alles voor i686 gecompileerd en is men altijd erg druk met enkele promilles snelheidswinst.
En ik zie dat ze ook live CD's hebben, een -niet geheel onverwacht- 32-bits en een 64-bits exemplaar.

[Koen_92]

Misschien probeer ik Gentoo nog wel eens
Ik moet wel zeggen dat compileren echt snel gaat op mijn nieuwe dualcore processor, bijna 2 keer zo snel als op mijn oude Pentium 4.

Live-cd's zijn leuk om voor het eerst Linux uit te proberen, maar ik vind dat je daarmee niet een distro kunt testen.
Als ik hem echt wil proberen, gebruik ik namelijk Virtualbox.

Zit er trouwens een verschil tussen i386 en i486?
Windows XP is namelijk nog voor i386 gemaakt.

De laatste versie van Slackware die voor i386 is gecompileerd is versie 9. (Is hier heel mooi te zien.
Ubuntu en Debian zijn op dit moment ook nog i386 gecompileerd.
Tijdens het installeren van Debian heb ik wel voor de i686 kernel gekozen. (En jij ook , aan je user-agent te zien)

[adri]

Ik heb tijdens het installeren voor de standaard kernel gekozen, kijk maar:

Code: Selecteer alles

adri@Slackware:~$ uname -a
Linux Slackware 2.6.27.7-smp #2 SMP Thu Nov 20 22:32:43 CST 2008 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux

Volgens mij is SW al geoptimaliseerd voor i686. Ik heb daar niet zoveel verstand van, maar ik lees er wel eens wat over en mensen die er wel verstand van hebben zeggen dat het allemaal lood om oud ijzer is.

[Koen_92]

Volgens distrowatch is SW voor i486 geoptimaliseerd, maar die kunnen het natuurlijk ook fout hebben.

Maar ach, waar zeuren we om?
Net of het verschil merkbaar is, en net zoals je zegt is het lood om oud ijzer

Maar wat betekent trouwens dat #2, dat bij jouw uname -a achter de kernel versie staat?
Ik heb daar namelijk #1 staan, en ben dus wel benieuwd naar het verschil :

Code: Selecteer alles

koen@debian:~$ uname -a
Linux debian 2.6.26-1-686-bigmem #1 SMP Fri Mar 13 18:52:29 UTC 2009 i686 GNU/Linux
koen@debian:~$ 

[adri]

Je hebt gelijk, SW is gecompileerd voor i486, maar in de SlackBuild scripts staat de mtune flag wel dusdanig dat als je een i686 machine hebt, de compilatie daar toch rekening mee houdt.
Ik heb bijv. hier een stukje uit het SlackBuild script voor Audacious:

Code: Selecteer alles

if [ "$ARCH" = "i386" ]; then
  SLKCFLAGS="-O2 -march=i386 -mcpu=i686"
elif [ "$ARCH" = "i486" ]; then
  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
elif [ "$ARCH" = "s390" ]; then
  SLKCFLAGS="-O2"
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2"
fi

Wat die #2 betekent weet ik ook niet.

Overigens, na jaren trouwe dienst zal bij de volgende Slackware release (en nu dus al bij -current) het vertrouwde .tgz pakketje gaan verdwijnen.
Dat wordt vervangen door .txz pakketjes. Die zijn blijkbaar wat sneller uitgepakt én nemen minder ruimte in beslag:

Hello folks! This batch of updates includes the newly released KDE 4.2.3, but more noticeably it marks the first departure from the use of gzip for compressing Slackware packages. Instead, we will be using xz, based on the LZMA compression algorithm. xz offers better compression than even bzip2, but still offers good extraction performance (about 3 times better than bzip2 and not much slower than gzip in our testing). Since support for bzip2 has long been requested, support for bzip2 and the original lzma format has also been added (why not?), but this is purely in the interest of completeness -- we think most people will probably want to use either the original .tgz or the new .txz compression wrappers. The actual Slackware package format (which consists of the layout within the package envelope) has not changed, but this is the first support within Slackware's package tools for using alternate compression algorithms. Some people have asked why we don't pick a single extension, such as .slk. While there's certainly a case to be made for that idea, the tools would still need to support .tgz to handle older packages. Sticking with ".tgz" for everything makes no sense. Using extensions that reflect the compression format used by the package envelope seems to be the most transparent approach, and the one that best follows tradition. As an example of the compression improvement with .txz, have a look at the kernel-source package:
Before: kernel-source-2.6.29.2_smp-noarch-1.tgz (73808508 bytes)
After: kernel-source-2.6.29.2_smp-noarch-1.txz (49150104 bytes)
The size of the main package tree in /slackware has been reduced from 1.9GB to 1.4GB by converting most packages to .txz. Most of the packages have been converted from .tgz to .txz, but we will continue to make the gzip, pkgtools, slackpkg, tar, and xz packages in .tgz format for the foreseeable future.
Enjoy! And thanks to Lasse Collin for the great work on xz.

.

[Koen_92]

Ok, bedankt voor de info.
Het is nu een stuk duidelijker.

Dit is denk ik ook één van de redenen waardoor de performance van een zelfgecompileerd package hoger ligt dan die van kant-en-klare packages.
Bij kant-en-klare packages wordt waarschijnlijk 'op safe gespeeld' door ze voor i486 te compilen, terwijl je dan met slackbuildscripts voor i686 gaat bouwen indien mogelijk.

[common sense]

Wat die #2 betekent weet ik ook niet.

(Re)build nummer?

[adri]

Zou kunnen.
Ik gebruik momenteel de hugeSMP.
Zal het wel eens in de gaten houden als ik een andere installeer.

[Koen_92]

Heb jij dan een andere kernel gecompileerd, adri?
En verder:
Waarom gebruik je Huge, en niet generic?

There are two kinds of kernels in Slackware -- the huge kernels, which
contain support for just about every driver in the Linux kernel. These are
primarily intended to be used for installation, but there's no real reason
that you couldn't continue to run them after you have installed. The
other type of kernel is the generic kernel, in which nearly every driver
is built as a module.

[adri]

Heb jij dan een andere kernel gecompileerd, adri?

Momenteel in SW 12.2 niet.

En verder:
Waarom gebruik je Huge, en niet generic?

There are two kinds of kernels in Slackware -- the huge kernels, which
contain support for just about every driver in the Linux kernel. These are
primarily intended to be used for installation, but there's no real reason
that you couldn't continue to run them after you have installed. The
other type of kernel is the generic kernel, in which nearly every driver
is built as a module.

Tja, hij voldoet goed, dus waarom zou ik het veranderen.