thelinuxlink.net

You guys were talking about the upcoming Slackware 11 and the fact that Pat V. is going to stick with the 2.4 kernel as the default, which has been pretty clear, IMHO, from the -current changelog the last few months. 2.6 is still in /testing and it will be available as an option during install, but 2.4 will still be the default.

Anyway, the point of my post is that there has been some discussion on the LQ Slackware forums about version 11 and one poster allegedly emailed Pat about some of these issues and here is what this poster says that Pat told him:

> That means you are preparing for the Slackware 11.0 release right now?
> Will you stick to 2.4.x kernel or start using 2.6.x kernel in Slackware
> 11.0?

You'll see, right?

OK... I guess. 11.0 will use both. I strongly believe that the 2.4
kernel has very good performance, and is more stable and more secure,
and do not use 2.6 except where I need a new feature that is only
present there (as well as for testing purposes, of course).

11.1 will probably dump support for 2.4.x, as well as archaic things
like the "boot floppy".

And:

> yes, but it didn't support as many hardware as in 2.6.x kernel right?
> And it didn't changes so much since 10.2 been released almost 9 months ago
> I do believe that 2.4 is more stable, but some problem arises when using
> 2.4.x kernel, such as udev, ATI drivers, etc

Some believe that udev was a bad idea.

As far as ATI drivers, use 2.6.x then. But I'm not going to make the
default less secure so that someone can be ready to play 3D gaming out
of the box. I'm more concerned with the people using servers than desktops.

>> 11.1 will probably dump support for 2.4.x, as well as archaic things
>> like the "boot floppy".
>
> what do you mean by support for 2.4.x?

I mean it is not included any more. Gone.

So, assuming Pat V. really did say those things (and it does sound like him, based on emails that I have had with him) then I think it's interesting in that it shows his thought process here. He is obviously very conservative and is more concerned with server stability than desktop gaming or whatnot.

Just thought I'd share.

Edit: forgot to link to the LQ thread (it's a 14 page thread, and this link is to the last page where these posts come from):
http://www.linuxquestions.org/questions ... 93&page=14

He is obviously very conservative and is more concerned with server stability than desktop gaming or whatnot.

Not to steal the spotlight off of Slackware in this post, but this is another reason, in addition to many others, why I like using SUSE, because Novell has a big focus on the desktop, I don't think that directly affects me, but I get a good feeling by "supporting" the people who focus on the desktop.

Not to steal the spotlight off of Slackware in this post

Seriously dude, I was glad to see some pro-Slack stuff.

johnnywtllts wrote:

Not to steal the spotlight off of Slackware in this post

Seriously dude, I was glad to see some pro-Slack stuff.

Slackware is a cool distro man, not bashing it in any ways, it's just too much work for me, and I've not had a dependency issue in 1½ years, so I don't see the fuss about having a package manager that calculates dependencies.

Tsuroerusu wrote:I don't see the fuss about having a package manager that calculates dependencies.

Just to play Devil's Advocate here...

Package managers that calculate dependencies are not perfect. Apt-get is supposed to be the end-all and be-all of package managers. How many times have all of us heard or read about a Debian user who fubared their system because of an upgrade or something? Sure, if you stick with just stable, then you are ok, but that's the same thing as sticking with initial set of packages of any distro, including Slackware. It's when you go outside that stable repository that you can introduce problems.

I have Arch on one of my workstations and I love it. Pacman is great. But, I have had breakage. Nothing that I couldn't fix, but still, the package manager that calculated dependencies caused the problem. On my Slackware system I never have dependency problems.

I'm not saying it's for everyone. And, I'm not saying I don't use apt-get or pacman because I do and it is nice. But, (remember, I'm playing Devil's Advocate, here), the idea of not using a package manager that calculates dependencies is not as crazy at it seems. If you do the dependency checking and compiling yourself, then you really tend to avoid those problems. I don't compile everything, of course, like KDE or GNOME, but for the "extras", compiling yourself tends to reduce problems. It not as easy, and takes longer, but it tends to be more stable in the long run.

Chess wrote:

Tsuroerusu wrote:I don't see the fuss about having a package manager that calculates dependencies.

Just to play Devil's Advocate here...

Package managers that calculate dependencies are not perfect. Apt-get is supposed to be the end-all and be-all of package managers. How many times have all of us heard or read about a Debian user who fubared their system because of an upgrade or something? Sure, if you stick with just stable, then you are ok, but that's the same thing as sticking with initial set of packages of any distro, including Slackware. It's when you go outside that stable repository that you can introduce problems.

OK, I think you just mixed two things together there for a minute Chess.
Most geeks who use Debian as their desktop system, most likely don't use vanilla stable, because it's just so outdated by now in terms of KDE, GNOME and all the bells and whistles, so they either add backports repositories or use either the testing or unstable branches.
Testing and unstable are development branches, stuff that you're not supposed to use on "production" systems, sure a lot of advanced users will argue, myself included at times, that it's fine, but it's not guaranteed in any way.
Also, concerning upgrades, a few days ago I wanted to see if SUSE really was as bad at upgrading as it is in my experience, and what I found was that if I just installed SUSE and just used it the way the distro was supposed to and not tweaking the multimedia support and stuff, not adding some mime type stuff, I could easily do an upgrade it worked perfectly, and I started with 9.1 Personal and upgraded all the way to 10.1 and no problems at all. I'm sure this goes for Ubuntu as well, and after hearing about the issues with upgrading Ubuntu on the tech show I realized something, the distro maintainers just can't take into action, how you tweak your system, and if you use 3rd party repositories that some where in the linkage corner some dependencies up against the wall, you introduce issues, sure Slackware won't bug you about this, but IF something is fubared you need to go dig for the issue yourself, which I find a big pain in the butt.
Something I noticed on SUSE is that because there aren't that many community repositories, most people primarily use two, the guru and packman repositories, there are rarely dependency issues, on Fedora you have some repositories mirroring each other's work so you can't use them together.

Chess wrote:I have Arch on one of my workstations and I love it. Pacman is great. But, I have had breakage. Nothing that I couldn't fix, but still, the package manager that calculated dependencies caused the problem. On my Slackware system I never have dependency problems.

I think Arch is a little bit of a special case, because compared to Debian, how many testers and developers does it have? And because it aims so strictly at experienced users, you also limit the number of people who can report the issues, even if it's just by a margin.

Chess wrote:I'm not saying it's for everyone. And, I'm not saying I don't use apt-get or pacman because I do and it is nice.

Smart has some interesting solutions to dependency issues, there are several ways of locking a package so you can't install or uninstall a package and if you get a dependency issue, you just use the lock feature in the apropiate places and it won't bug you, takes 10 - 30 seconds, for example, recently the Packman guys had a rare screw up, because they accidently made the vlc package depend on a specific version of ffmpeg I believe so you couldn't install vlc and upgrade MPlayer at the same time, so what I did before they issued and update was that I uninstalled VLC, upgraded MPlayer, used YaST to install VLC as it can completely ignore the dependency issues, and then in Smart I locked VLC, and then it didn't bug me at all, took me no time at all to do.

Chess wrote:But, (remember, I'm playing Devil's Advocate, here), the idea of not using a package manager that calculates dependencies is not as crazy at it seems. If you do the dependency checking and compiling yourself, then you really tend to avoid those problems.

Sure, but in my mind you introduce a lot of additional complexity, because you need to go to tools like ldd or stuff like that to figure out what's wrong and increases the amount of time to install larger stuff, like Mono for example, which Dann said is a bitch to install on Slackware
Sure you can fault Miguel and his boys for not sticking with the classic UNIX saying of KiSS, but Mono is really not something you can do simple, especially since to a degree it's derived from some Microsoft designs.

Chess wrote:I don't compile everything, of course, like KDE or GNOME, but for the "extras", compiling yourself tends to reduce problems. It not as easy, and takes longer, but it tends to be more stable in the long run.

Now see, this is where I get confused, what's the difference between this and running Gentoo, because as CptnObvious999 pointed out to me, there are binary packages available for the big apps like KDE and OpenOffice. For example you can get a Gentoo system running relativly quickly with KDE or GNOME, and just compile the extra stuff yourself.
I can also do this with FreeBSD which has a binary package collection of over 14,000 and rapidly closing in on Debian, also it allows you do to stuff like edit the actual dependencies so if there's a naming issue I think you can just correct that, you can certainly just edit the makefile that make up an entry in the BSD Ports system, which is just a hairy-ass Makefile infrastructure.

My decision to run Slackware up to this point has been pretty simple...it's the only full-blown distro that has worked worth a dang on my POS hardware (6 year old laptop - runs beautifully with XFCE - 9 year old desktop running Wordpress page on LAMP), and besides....it is cool.

I've recently acquired a "new" MSI mobo w /AMD 64 +3000 and have been running Ubuntu on it for the last month. I "broke down" today and set aside a partition on it to try out Suse ***(Ubuntu is working fine, but after hearing so much about Suse, wanted to try it)***

With Ubuntu, I had trouble installing 64 bit Dapper and just installed the x86 version. I took for granted that Suse x86 would work also and just downloaded it.

I've tried twice now to install it and it freezes with about 104 packages left on CD1 - the last thing it had done was load the kernel. I'm now downloading the X86-64 CDs (torrent).

So, if Pat plans on completely removing the 2.4 kernel for 11.1, why not just make the move to 2.6 for the big 11.0 release? He claims that the 2.4 kernel provides better security, and stability, but he's going to ditch it in 6-9 months anyway? Why put off the inevitable? Just make the 2.6 kernel the default already, and offer a 2.4 option during installation.

This just hit the -current changelog (how cool is it that his wife compiles the Slackware kernels!)

Fri Jul 14 18:31:20 CDT 2006
We *are* getting closer to 11.0, friends.
I'm hoping for a larger changeset soon, but this should be fun to play with
for now as I work on the TODO list; merging, compiling, and initial testing.
n/samba-3.0.23-i486-1.tgz: Upgraded to samba-3.0.23.
This fixes a minor memory exhaustion DoS in smbd.
The CVE entry for this issue may be found here:
http://cve.mitre.org/cgi-bin/cvename.cg ... -2006-3403
(* Security fix *)
kernels/huge26.s/*: Upgraded huge26.s kernel to 2.6.16.24.
The name of the big kernel with many built-in options has been changed from
test26.s to huge26.s to reflect that Slackware 11.0 will consider the
2.6.16.x kernel series to be a supported kernel series. However, I'm
probably going to leave the bare.i 2.4.32 kernel as the default kernel (or
perhaps sata.i?) as it has very good performance and probably better security
due to the simpler and longer-tested design. I might apply or at least make
available in the kernel-source package for 2.4.32 a patch to fix direct
rendering with 2.4.x kernels and X.Org 6.9.0 or newer. Since anyone using
Slackware for server use isn't likely to be loading the DRI modules, it's
untouched code on those machines and won't affect server stability (well,
depending on what, if anything, outside of the module is changed in the
kernel). It is probably a safe enough patch to apply. I'd rather ship 100%
vanilla kernels (and might, with the patch "on the side"), but DRI does not
work without the patch past X.Org 6.8.2. Is this enough text here?
Perhaps I should rename this my "ChangeBlog".
Thanks to Andrea Volkerding for compiling these kernel packages:
extra/linux-2.6.16.24/alsa-driver-1.0.11_2.6.16.24-i486-1.tgz:
Upgraded to alsa-driver-1.0.11 compiled for Linux 2.6.16.24.
extra/linux-2.6.16.24/kernel-generic-2.6.16.24-i486-1.tgz:
Upgraded to Linux 2.6.16.24 generic kernel.
extra/linux-2.6.16.24/kernel-headers-2.6.16.24-i386-1.tgz:
Upgraded to Linux 2.6.16.24 kernel headers.
extra/linux-2.6.16.24/kernel-modules-2.6.16.24-i486-1.tgz
Upgraded to Linux 2.6.16.24 kernel modules.
extra/linux-2.6.16.24/kernel-source-2.6.16.24-noarch-1.tgz
Upgraded to Linux 2.6.16.24 kernel source.
testing/packages/linux-2.6.17.4/kernel-generic-2.6.17.4-i486-1.tgz:
Upgraded to Linux 2.6.17.4 generic kernel.
testing/packages/linux-2.6.17.4/kernel-headers-2.6.17.4-i386-1.tgz:
Upgraded to Linux 2.6.17.4 kernel headers.
testing/packages/linux-2.6.17.4/kernel-modules-2.6.17.4-i486-1.tgz
Upgraded to Linux 2.6.17.4 kernel modules.
testing/packages/linux-2.6.17.4/kernel-source-2.6.17.4-noarch-1.tgz
Upgraded to Linux 2.6.17.4 kernel source.