The Ultimate "When Will The Next Slackware Release Arrive" MegaThread
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Slackware personally & for all servers/Customized Fedora Core for clients/customers desktops
Posts: 30
Rep:
Quote:
Originally Posted by win32sux
i thought he said he was sticking with it for now, but that after this it was 2.6 all the way...
I remember reading that too. And from my experiences using the 2.6 kernels, it's now matured to the point of being just as stable as the 2.4 series. Using 2.6 has also solved numerous problems I've had in the past using 2.4 kernels, especially with new boxes using new hardware.
when i click on the link in the notification mail for this thread i'm being taken to the previous page instead of this one... anybody else experiencing this??
I wasn't saying that hal wasn't working I was saying that KDE 3.5.4 wasn't working correctly with or without hal. And that is very dissapointing. And I was refuring to the thread on the forum dealing with hal and also the linuxpackages and what ever else I could find. They may not be doing it correctly but it was alot more then just ./configure && make && make install.
"Effort" only counts in kindergarden. These people could struggle for days, non-stop, and it's not going to make the thing work unless they're doing the right things, and that only happens when someone sets aside the time to study HAL and its interaction with the kernel and the nature of the hardware events that HAL waits for.
Quote:
Originally Posted by Myah
I also am not trying to pimp my OS. I just thought maybe people wanted to know what I was saying. But I was expecting some kind of cheap comeback like that. Oh well. Or something like stay on your forum. Or rude people are the slackware way. All greate aditudes. I also noticed all those people just like to argue and none wanted to answer the very first simple question.
Yes, I'm seeing right now how you must be a consummate Slackware user because you're being both rude and willfully ignorant of new information. I answered your question about the SMP kernels and you're still claiming "none" answered you.
Quote:
Originally Posted by Myah
About the SMP still clear as mud LOL I'm wondering if it will break support for non HT or multicore CPUS. I do understand the the i486 and i586 are left out. and It's find for me since those wouldn't run the X Desktop and other software very well anyway.
If it's somehow still clear as mud to you, I'll make it simpler still. Don't use an SMP kernel unless you have more than one CPU in your machine, or a multi-core CPU in your machine. Do use an SMP kernel if you have more than one CPU in your machine, or a multi-core CPU in your machine.
Last edited by evilDagmar; 09-18-2006 at 04:47 PM.
I didn't read the rest of your post because that was all I needed to read to see what kind of person was talking.
You mean an educated person?
Quote:
Originally Posted by myah
I know what an SMP kernel does I'm not stupid. I was just asking if it breaks or hinders the running proccess or standard CPU's. And if you never ask you never learn.
You could have fooled me. There's much documentation about SMP kernels that goes into detail as to why they're not useful on UP machines. If you're going to act like a touchy little noob all the time, you should probably get used to researching documentation because if you piss everyone off it won't matter whether you ask because no one will answer you--you'll only get answers from search engines.
11.0 2.4 and 2.6 both supported kernels
11.1 2.6 only
I spotted something in the Changelog that after digging some more I really don't much mind anymore that he's shipping the 2.4.x kernels as the standard.
For awhile I've been running into things I have to patch around where since the API for parts of the kernel have changed, things linking to kernel bits and using headers in /usr/include/linux just break or simply refuse to work properly because of the 2.4.x headers sitting in there. This time around he's apparently (haven't had time to test much to be 100% sure it doesn't cause other problems, but I "reasonably trust" PV) done something I didn't even know was possible that makes glibc's libraries from /lib take effect when running a 2.4.x kernel, and a different build of the libraries (done with a 2.6.x kernel present) sitting in /lib/tls take effect when running a 2.6.x kernel. For people trying to build new things that make use of USB or Video4Linux2, that means they don't have to keep the 2.4.x linux kernel headers in /usr/include/linux--they should be able to safely generate a set of header files from the 2.6.17.13 (I think that was the one, and *) and put those in /usr/include/linux and their compiling problems will go right away.
* - It's important to mention that I don't mean just any 2.6.x kernel headers. If he built that glibc against 2.6.17.13, then that is the only version of the kernel headers that should be used as a replacement, not 2.6.18's headers when they come out, and not even 2.6.17.12's headers.
This time around he's apparently (haven't had time to test much to be 100% sure it doesn't cause other problems, but I "reasonably trust" PV) done something I didn't even know was possible that makes glibc's libraries from /lib take effect when running a 2.4.x kernel, and a different build of the libraries (done with a 2.6.x kernel present) sitting in /lib/tls take effect when running a 2.6.x kernel.
wait, i'm not sure i'm following you... are you referring to the historic upgrade he did to glibc back in may of last year??
Quote:
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:
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)
This time around he's apparently (haven't had time to test much to be 100% sure it doesn't cause other problems, but I "reasonably trust" PV) done something I didn't even know was possible that makes glibc's libraries from /lib take effect when running a 2.4.x kernel, and a different build of the libraries (done with a 2.6.x kernel present) sitting in /lib/tls take effect when running a 2.6.x kernel.
Quote:
Originally Posted by win32sux
wait, i'm not sure i'm following you... are you referring to the historic upgrade he did to glibc back in may of last year??
It does pay off to actually read the documentation Pat writes. The 2.4/2.6 glibc/headers/NPTL issue has come up a zillion times now, and everyone adds to the confusion.
I propose everyone reads README.NPTL and extra/linux-2.6.17.13/kernel-headers.WARNING and let that oscillate in his or her head until after 11.0 is released.
It does pay off to actually read the documentation Pat writes. The 2.4/2.6 glibc/headers/NPTL issue has come up a zillion times now, and everyone adds to the confusion.
I propose everyone reads README.NPTL and extra/linux-2.6.17.13/kernel-headers.WARNING and let that oscillate in his or her head until after 11.0 is released.
Eric
ummm, that's like the same thing that was in the changelog well over a year ago, though... which is why i found it kinda odd that evilDagmar seemed to only find-out about it now... when i read his post i actually checked the -current changelog to make sure there hadn't been some kinda _new_ change to the glibc strategy...
It does pay off to actually read the documentation Pat writes. The 2.4/2.6 glibc/headers/NPTL issue has come up a zillion times now, and everyone adds to the confusion.
Personally, I've always left the 2.4 headers in place, because I thought I read somewhere that installing the 2.6 headers could still cause breakage. This is despite the fact that I've been running a 2.6 kernel since the day 2.6.0 was released.
Using this stragegy, the only package I've seen to date which didn't compile on my machine against the 2.4 headers was HAL, which actually needed to be compiled against the "sanitised" 2.6 libc headers by Mariusz Mazur available from here: http://ep09.pld-linux.org/~mmazur/linux-libc-headers/.
I've compiled hundreds of custom software packages on my Slackware machine and found that everything (and I mean EVERYTHING) else I've ever compiled has worked with the 2.4 headers.
Also, I recall reading a comment from a kernel developer which suggested that only insane people would compile against "raw" 2.6 headers. To be honest, I don't understand any of the technical reasons as to why. It seems to me that the goal posts on the 2.6 field are still being shifted around quite a bit. I am still wondering what Pat'll do when Slackware switches to 2.6. Will he package the raw 2.6 kernel headers? Or will he package a "sanitised" set?
and while we're at it... what exactly are sanitized headers?? and why can't they come sanitized from kernel.org?? it feels odd that the official kernel headers are, ummm, unsanitary... =/
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
