A képernyõvédõt miért nem magával a progival állítod be???

Figyelem aki a current ágat használ és frissiteni szándékszik az csak óvatosan!!!
http://forum.index.hu/Article/viewArticle?…60667&t=9057690

http://www.banki.hu/~ferencza/salak_book/

HMMM igen fut de csak 32 bitesen…
Ha élvezni akarod a vasad minden erejét akkor tegyél fel egy 64 bites Linuxot..

Rengeteg-rengeteg változás a Current ágban…
http://www.slackware.com/changelog/current.php?cpu=i386

Fri May 13 12:51:03 PDT 2005
Here’s the (I’m sure) long awaited upgrade to Slackware’s glibc to
include support for NPTL (the Native POSIX Thread Library). NPTL
works with newer kernels (meaning 2.6.x, or a 2.4 kernel that is
patched to support NPTL, but not an unmodified „vanilla” 2.4 kernel
such as Slackware uses) to provide improved performance for threads.
This difference can be quite dramatic in some situations. For example,
a benchmark test mentioned on Wikipedia started 100,000 threads
simultaneously in about 2 seconds on a system using NPTL. The same
test using the old Linuxthreads glibc thread support took around 15
minutes to run! For most applications that do not start large numbers
of threads the difference will not be so large, but for high traffic
servers, databases, or anything that runs large numbers of threads,
NPTL should bring big improvements in scalability and performance.
For compatibility, the regular (linuxthreads) libraries are installed
in /lib, and the new NPTL versions are installed in /lib/tls. Which
versions are used depends on the kernel you’re using. If it’s newer
than 2.6.4, then the NPTL libraries in /lib/tls will be used. TLS
stands for „thread-local storage”, and the directory name /lib/tls is
a little bit misleading since now both the linuxthreads and NPTL
versions of glibc are compiled with TLS support included (this is
needed to produce versions of tools such as ldconfig that can run under
either kind of system).

Getting all the kinks out of the build script to be able to get this to
work with either 2.4 or 2.6 kernels and be able to switch back and forth
without issues was quite a challenge, to say the least, and would have
been much harder without all the good advice and help folks sent in to
help me along and give me important hints. A special thanks goes to
Chad Corkrum for sending in some ./configure options that really helped
get the ball rolling here.

Here’s some information about compiling things using these libraries —
by default, if you compile something the headers and shared libraries
used to compile and link the binary will be the linuxthreads versions,
but when you go to run the binary it will link to the NPTL library
versions (and you’ll get the NPTL speed improvements) if you are running
an NPTL capable kernel. In rare cases you may find that an old binary
doesn’t work right when run against the NPTL libs, and in this case you
can force it to run against the linuxthreads versions by setting the
LD_ASSUME_KERNEL variable to assume the use of a 2.4.x (non-NPTL) kernel
so that NPTL will not be used. An easy way to see the effect of this is
to try something like the following while using an NPTL enabled kernel:
     
      volkerdi@tree:~$ ldd /bin/bash
      linux-gate.so.1 => (0xffffe000)
      libtermcap.so.2 => /lib/libtermcap.so.2 (0xb7fcf000)
      libdl.so.2 => /lib/tls/libdl.so.2 (0xb7fcb000)
      libc.so.6 => /lib/tls/libc.so.6 (0xb7eaf000)
      /lib/ld-linux.so.2 (0xb7feb000)

Note that in the example above, the binary is running against the NPTL
libraries in /lib/tls. Now, let’s try setting LD_ASSUME_KERNEL:

      volkerdi@tree:~$ LD_ASSUME_KERNEL=2.4.30 ldd /bin/bash
      linux-gate.so.1 => (0xffffe000)
      libtermcap.so.2 => /lib/libtermcap.so.2 (0xb7fcf000)
      libdl.so.2 => /lib/libdl.so.2 (0xb7fcb000)
      libc.so.6 => /lib/libc.so.6 (0xb7eb2000)
      /lib/ld-linux.so.2 (0xb7feb000)

As you can see, now the binary is running against the linuxthreads
version of glibc in /lib. If you find old things that won’t work with
NPTL (which should be rare), this is the method you’ll want to use to
work around it.

Now for a little note about compiling things. In most cases it will be
just fine to compile against linuxthreads and run against NPTL, and this
approach will produce the most flexible binaries (ones that will run
against either linuxthreads or NPTL.) However, in some cases you might
want to use some of the new functions that are only available in NPTL,
and to do that you’ll need to use the NPTL versions of pthread.h and
other headers that are different and link against the NPTL versions of
the glibc libraries. To do this you’ll need to add these compile flags
to your build in an appropriate spot:

      -I/usr/include/nptl -L/usr/lib/nptl
      (and link with -lpthread, of course)

Have fun, and report any problems to volkerdi@slackware.com.

a/glibc-solibs-2.3.5-i486-1.tgz: Upgraded to glibc-2.3.5 shared libs.
a/glibc-zoneinfo-2.3.5-noarch-1.tgz: Upgraded to time zone files from
      glibc-2.3.5.
l/glibc-2.3.5-i486-1.tgz: Upgraded to glibc-2.3.5.
l/glibc-i18n-2.3.5-noarch-1.tgz: Upgraded to glibc-2.3.5 i18n files.
l/glibc-profile-2.3.5-i486-1.tgz: Upgraded to glibc-2.3.5 profile libs.
xap/gaim-1.3.0-i486-1.tgz: Upgraded to gaim-1.3.0. This fixes a few
      bugs which could be used by a remote attacker to annoy a GAIM user by
      crashing GAIM and creating a denial of service.
      (* Security fix *)
extra/linux-wlan-ng/linux-wlan-ng-0.2.1pre25_2.6.11.9-i486-1.tgz:
      Recompiled linux-wlan-ng-0.2.1pre25 for Linux 2.6.11.9.
testing/packages/linux-2.6.11.9/alsa-driver-1.0.8_2.6.11.9-i486-1.tgz:
      Recompiled for Linux 2.6.11.9.
testing/packages/linux-2.6.11.9/kernel-generic-2.6.11.9-i486-1.tgz:
      Upgraded to Linux 2.6.11.9. Note that as far as these so-called
      „sucker” kernels go, I won’t be intending to follow every one that’s
      released, but I figure I might as well upgrade _occasionallly_, as
      there’s no reason to be testing for bugs that are already well-known.
      Anyway, I guess my point here is that when 2.6.11.10 comes out (if it’s
      not out already ;-), I won’t need everyone to be sending me email saying
      „new kernel! new kernel!”. If, on the other hand, you are personally
      affected by a kernel bug that’s fixed by a new kernel in this series
      feel free to let me know about it. Thanks! 🙂
testing/packages/linux-2.6.11.9/kernel-headers-2.6.11.9-i386-1.tgz:
      Upgraded to kernel headers from Linux 2.6.11.9.
testing/packages/linux-2.6.11.9/kernel-modules-2.6.11.9-i486-1.tgz:
      Upgraded to kernel modules for Linux 2.6.11.9.
testing/packages/linux-2.6.11.9/kernel-source-2.6.11.9-noarch-1.tgz:
      Upgraded to kernel source for Linux 2.6.11.9.