Since about 2.6.34 or so, some important features, i.e. working remote controls and Gallium drivers for Radeon r600+ class hardware have been missing. Well, I'm pleased to report that my Hauppauge remote control and Radeon HD2600 are FINALLY working WELL due to Jarod's efforts to move LIRC into the kernel, Mauro for fixing the actual bug with Hauppauge's WinTV USB2, and AMD's help in getting Gallium drivers running for more of their hardware. As mentioned elsewhere, the increased speed on r600+ hardware with bleeding edge pulls of xf86-video-ati, mesa-7.11-devel, and libdrm is highly welcomed and significant. For me, the 2.6.38.x kernel is a big sigh of relief so far. In nearly 15 years, I've rarely used a "testing" kernel, but desperation forced my hand. If I were releasing the upcoming version of Slackware, I'd wait for the 2.6.38 kernel. Hopefully, I can now get more needed rest.

i don't that would happened though
next Slackware will be using 2.6.35.x series which is considered a long term kernel releases

1 members found this post helpful.

Personally, I think it's better to go with 35.10 for release (which is a long-term support kernel) and proven. From what I've read about 2.6.38 so far, there's a lot of "invasive changes" (linus' words) and linus himself was encouraging caution with these release candidates.

Better to ship something reliable and let those who need the latest and greatest add it themselves, IMO. That's not to say that I'm not looking forward to the goodies .38 brings.

3 members found this post helpful.

I also will not advise you to be so hurry. A few days ago I have updated kernel to 2.6.37 (from 2.6.33.4) and now I have problems with 3rd-party drivers(they are not compilable now). I have tried to trace incompatibilities in kernel sources, and made conclusion 2.6.36 kernel(and probably little older) will also be incompatible for me(but have not test it yet). Yes, trunk version of drivers from hardware manufacturer have fixed this issues, but there is not stability guarantee. So I decided to fall back to out-of-box kernel version.

Why not 2.6.36.3?

I believe these so called long-term support kernels are garbage, especially on other distros. (Who cares what ubuntu is doing here, when they'll break all their rules anyway?) What's the use of making intermediate stable kernel releases if people are discouraged from using them? I can believe Linus will caution people of invasive changes during a pre-release, but a stable release should be documented what to do by then. I am using 2.6.37 just fine and will be upgrading to 2.6.38 pretty soon. I have always been doing this with the kernel.

Not only has no official upstream long term support been declared for that kernel, but I have been continuing to read about regressions versus 2.6.35.x on the kernel [stable] mailing list.

4 members found this post helpful.

That's great. Other people might be depending on considerable uptime, and that will be the primary kernel goal here.

4 members found this post helpful.

While I'm inclined to agree with you to a point about the distro maintained kernels, I tend to look more favorably on the upstream long-term kernels on kernel.org.

Though one would hope that following the latest 'stable' upstream kernel should be reasonably reliable, the changes it can introduce can sometimes require updates to other components of the system. That's fine for rolling-release distros that are designed to work that way, but the more traditional release based distros that tend to end up on servers want to avoid unnecessary version updates.

The last thing you want to happen is to end up in the situation where you have to miss out on an important security update because something critical on your box doesn't yet work with the new stable kernel or a version of something that it is dependent on. This is what the long-term kernels are supposed to be about: You get back-ported kernel security updates, but no new features that would require other parts of the system to need updating.

I tend to agree with a large portion of your sentiments. In practice, the LTS kernels fall short of their goal. For example, the latest upgrade from 2.6.35.7 to 2.6.35.10 adversely affected some users of AMD/ATI's graphics cards so the goal of LT "stability" is relative and rarely achieved in practice. Another example is the problem with mounting or accessing optical discs on my MCP-61 motherboard. Ever since Slackware 13.0, optical disc performance has been just plain erratic with no end in sight. Although I don't know for sure, I suspect the problem with optical discs lies in the kernel and remains in 2.6.38-rc2 as well as 2.6.35.7.

Pat strives to provide the stablest kernel possible which is necessary for servers, etc. I understand both sides.

Lastly, I currently believe the problem with instability will only get worse until the Linux kernel shifts to a different structure similar to a micro-kernel.

No. I believe that the monolithic version is more stable than the micro-kernel.

The problem is that the kernel has become huge, and Linus loves to reinvent itself. Basically, a hardware manufacturer has no guarantee that the current ABI, there will be the next version. Therefore, all drivers must be in the kernel tree.

Take, for example, the video drivers. If there was a stable ABI, they could develop a separate package of DRM. You want to update your DRM driver? Just upgrade the DRM package.

I believe that the future solution to the kernel, is similar to X.org: Breaking source in a lot of smaller packages, with well-defined role. And some stable ABIs.

We'll have to agree to disagree. Pico kernels would even be better for stability.

A step in the right direction which will help stabilize the kernel somewhat. However, I currently don't believe that "stable" ABIs will completely solve the long-term problem with the instability of the Linux kernel. The number of components directly interfacing with the kernel is simply huge with the current design.

I use stable 13.1 k 2.6.33.4-smp. On second partition on my laptop, which I use for experiments I have istalled so long Slackware 12.1 kenel 2.6.24 for
gaming FPS Games and I needed propietary ATI drivers for old Mobility radeon X1350. I had problem with screaming fans on ondemand governor and propietary drivers.

I installed on this partition Arch linux kernel 2.6.37-smp only for experiments with Gallium drivers also for Radeon R520 class. (I am not experimenting with
Slackware, I always love use stable version which I am upgrade only if I need). This Gallim dirvers give me a little more 3D effect in games, but I had problem
with screaming fans too. (Listen audacious and fans for full power and laptop too hot). Old versions of radeon (mine can be 4-5 years old architecture) are
still problematic.

I am not so experienced, I dont know how differences are between arch and slackware kernel, but now I am very happy user of 13.1 stable, fans are going normal
when I am doing anything on my laptop. I just only want to say, I dont have good experiences with Gallim on 2.6.37 and mobility radeon X1350. Off course, on another
distro.

I guess someone thinks that Linus doesn't deserve a very high grade.

Anyway, I would not hold your breath waiting for that.