SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
This thread is for questions and comments about Slackware's (new) NPTL support.
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.
The complete text is in the Slackware-Current ChangeLog.
Originally posted by xushi On a side note, i know how pat likes security issues, etc.. but i'm quite shocked and confused to why he didn't include firefox 1.0.4 in the updates...
yeah, it's weird - i would have imagined he would have included 1.0.4 in there, considering it's just a binary re-packaging... but quite frankly, i've gotten used to these huge delays on patrick's behalf - and i've gotten to the point where i actually expect delays - so when 1.0.4 was released i made my own slackpack by downloading the 1.0.4 tarball from mozilla.org and the official 1.0.3 slackware buildscript and files from slackware.com... all i changed was the version numbers in the script and in mozilla-firefox-simple.diff.gz and everything seemed to fall into place nicely... there was no way i could wait for patrick to release the update, i mean 1.0.4 fixed some pretty nasty bugs which i wanted patched ASAP:
Yes, it is curious why there was no firefox-1.0.4 release
since the 'build' only takes a few seconds. Most of the time
is either spent downloading the binary, editing the SlackBuild
and the diff and gzipping the package.
Another curiosity - why is the diff gzipped? The file size
difference between gzipped or not is only 138 bytes (434 vs 296).
So, I can't seem to find any recent NPTL patches for 2.4.xx... Does this mean that 2.4 is completely gone from Slackware on the next release? What a pisser.... I ran into this problem with LFS 6.0... If you build glibc with NPTL your pretty much boned when it comes to running 2.4.... If you rebuild glibc with the older threading model, every single binary and lib on your system breaks... The only patch I could find was for a Redhat 2.4.22 kernel... You get numerous failures during the patch... Sigh... I still need to check out the export LD_ASSUME or whatever it was... Could it be that easy? I rather doubt it... exporting a run-time variable doesn't explain how your going to get past the "FATAL: Kernel too old" message when you bootup even tho you have modutils installed....
yeah, i haven't found any recent NPTL patches for 2.4 either...
BTW guys: patrick just released the firefox 1.0.4 package (finally)...
Sun May 15 20:12:03 PDT 2005
xap/mozilla-firefox-1.0.4-i686-1.tgz: Upgraded to firefox-1.0.4.
Two vulnerabilities found in Mozilla Firefox 1.0.3 when combined allow
an attacker to run arbitrary code. For more details, see: http://www.mozilla.org/security/anno...sa2005-42.html
(* Security fix *)
here's an NPTL paper i found which seems interesting:
For most application developers, changes between the 2.4 and 2.6 kernel families have little direct impact. However, kernel and system changes that affect how applications spawn and manage other processes and threads are a significant exception to this rule. This whitepaper discusses topics related to migrating existing applications to the 2.6 kernel and the Native POSIX Threading Library (NPTL).
Originally posted by subgenius Yes, it is curious why there was no firefox-1.0.4 release
since the 'build' only takes a few seconds.
Our requests have been answered =) New changelog (Sunday).
Anyway, from what i keep reading, NTPL support falls mainly within the compiler itself. So i guess we won't see much performance increase until most of the applications are recompiled again with the new C compiler Pat just added.
I wonder if NTPL is used in *BSD and *NIX (Solaris) Operating Systems.
Edit: ... N PPPP T L ... And i just got used to spelling CORBA correctly
Originally posted by xushi I wonder if NTPL is used in *BSD and *NIX (Solaris) Operating Systems.
yeah i asked myself the same thing... i wonder which operating systems have been making use of NPTL already... i have a feeling FreeBSD and Solaris probably do, but i know nothing about UNIX... anyone know for sure?? it's just curiosity...
also, does anyone know which linux distros have been using NPTL??
Originally posted by win32sux making use of NPTL already
Although redhat, slack, and a few other distros have it enabled now, from my understanding (but don't quote me on this), i doubt any OS can truely take advantage of it until most of the apps are recompiled again.
64-bit Java and NPTL
Threaded 32- and 64-bit development on RHEL3 can be done with NPTL or the older Linux Threads libraries. However, only the NPTL 64-bit threading libraries are supported for Java. LinuxThreads is not supported with the 64-bit version of the IBM JDK 1.4.2 for Linux on POWER.
And see "Solaris thread and NPTL". It looks like Solaris already takes advantage of NPTL
I had read something similar to that. That sort of confirms my suspicions that the nvidia driver might not be properly detecting like it should. (I have nvidia headaches all the time)...
So this whole NPTL issue is of great concern to me... It's quite possiblly the biggest change to hit slackware, well, ever I guess.... His changelog is misleading in my opinion... He states that it's 2.4 backwards compatable but yet fails to mention that no one is actively backporting NPTL to the stable kernel branch... That effectively kills 2.4.xx for good once the new glibc is integrated into slackware. This upsets me because I really don't like the 2.6 branch. It's still too young and causes many problems for me, as I'm sure it does alot of people out there. I can't even run 2.6 on my new desktop. It barely works on my older laptop.
Anyway... If anyone hears of some recent NPTL patches for 2.4.xx, PLEASE post them here...
I've modeled my recent LFS after Slackware only I built glibc with nptl as mentioned above. I'm now looking at dropping slackware completely and rebuilding LFS 'old-school' to make that my permanent distro. That prospect doesn't appeal to me just because of the sheer ammount of work involved (yet again)...