Couldn't you just stick that same code into the rc.6 script?

1 members found this post helpful.

(Somehow I've missed this thread for 4 months?!?) The thing that I most dislike about Slackware is that it continues to be a long term paradox. Each release seems like the Greatest Thing Ever (sometimes even to the point of where I say it's "perfect") but then the next release comes out and it's even better... better than perfect?!? Now I have the strange situation of having to answer the question, "So, how's the new release of Slackware?" with "Well, not as good as the next one will be, but still... absolutely perfect." Darn it all to heck, Slack team, you give me nothing to complain about, nothing to hate, nothing to have to apologize for. Just an ever more amazing computing experience! For which I say, thank you very much.

Yeah, it's true Slackware is better than perfect ... that should be the new motto.

Yeah, but then you'd have to merge the change with every release.

There is no rc.local_shutdown in any of the packages, so that's not a problem.

Forgive me if this is a dumb question, but scripting is something I'm not very experienced with. How do you ensure that it's going to execute on shutdown rather than bootup?

If executable it's called by /etc/rc.d/rc.0, rc.K and rc.6, only.

PS In Slackware rc.0 is a symlink to rc.6

Terrific; thanks.

Probably has been said, but I hate the fact that Slackware still uses lilo as the default bootloader. Lilo is simply antithetical to the flexibility of the entire system, and it's always the very first thing I throw overboard.

-A

Why do you hate lilo? I find lilo to be very flexible, it does what I want it to do. It boots Slackware perfectly and it also allows me to easily boot other operating systems on the same PC(Windows, FreeBSD, etc.)

The kernel 2.6.33.4. Why not chosen kernel 2.6.32.15 ?( long term support )

Because it was not yet out at time of Slackware release, I guess

Why not 2.6.27.47 then, LOL

I also regret that choice.

Slackware 12.2 worked out wonderfully for me as it used the 27 series which was the previous long-term kernel.

Greg K-H has already announced that 2.6.33.6 will most likely be the last in the 33 series so 13.1 is going to find itself with an unsupported kernel very early in its lifetime. Updating to a newer branch is an option, but that means that your platform is no longer "stable", which may be a factor for some folk.

Big players like RedHat, Canonical, and Novell, and maybe even debian have the resource to back-port important kernel updates to their stable releases once the kernel devs drop support. The Slackware team aren't in a position to do this, so choosing the right release kernel is all the more important.

IMO Slackware got this one wrong this time. It's too late to do anything about it now though. That horse has already bolted, but there's possibly a lesson here for the future.

The .32 branch was announced as a long-term kernel a good month or so prior to .33 hitting current. I was very surprised to see .33 hit current at the time.

I know you were being sarcastic about .27, but the difference is that .32 is not obsolete. It's the current long-term supported kernel. In some respects it's more valid a choice than .33 is now because .33 has already been superseded by .34.

It is not common practice for Slackware to add new kernels to the patches section of a stable release - except in some cases to plug a critical hole.

No one is stopping you from adding a new kernel to your Slackware system. Unlike Redhat/Novell who keep backporting fixes and enhancements from new kernels to old releases, Slackware assumes that you pick the kernel that suits you best. The use of vanilla kernels in Slackware makes a switch very easy.

The 2.6.33.x kernel was kept in Slackware 13.1 because it works with some devices that are not supported by the 2.6.32.x kernels (at least some netbook network cards), as well working better with our X.Org for Ati cards in particular. Also, ARMedslack required something newer than the 2.6.32.x kernel.

Eric

While it's true that most people can just track the latest kernel branch and make their own custom builds to keep updated, there are times when stability(in the non-changing meaning of the word) is desired and the long-term support kernel is provided for that purpose.

Though new kernels tend to be backwards compatible with older kernels and the libc/headers built against them, I'm not convinced it's safe to run an older kernel on a system with a libc and headers built from a more recent kernel. You might get away with it of course, but the danger is that a new kernel interface/feature was introduced and made use of in the library/headers and when you run on the older kernel that feature will not be available.


What I'm suggesting is that it's better to freeze libc/headers for the latest long-term kernel, regardless of whether you include a more recent kernel as a default runtime kernel as this will allow people the option to run either the default or revert to the long-term kernels if stability is important to them. If you wanted to be extra nice you could even include the long-term kernel in /extra as an option.

The nice thing about Slackware 12.2 coinciding with the long-term kernel was that it was possible to follow 2.6.27.y all the way up to 2.6.27.47 (released just a few weeks back). If Slackware 13.1 had shipped with the option of using 2.6.32, it would have been good for at least a good year or so, just like 12.2 turned out to be.