So, we should do a complicated and errors prone flow to "upgrade" the kernel package just because the Slackware packages are perfect and the lack of preservation of previous kernel is perfect?

I love Slackware, but I do not think it or its kernel packages are perfect. In fact, I believe that nothing in this world is perfect, and always is room to improve. Including the Slackware itself. After all, it's not the Holly Bible.

You guys ever thought about how complicated would be for Slackware to preserve the previous kernels while upgrading their packages?

I know, I know, it's unthinkable, but there's a simple way:

The files from the kernel packages are versioned, so if we put them in an "incoming" directory to have them out of the scope of removepkg, we can move them in the proper place with the post install script.

Imagine that we have kernel-generic-5.15.19 and we upgrade to kernel-generic-5.15.20 while using this method. The files from the new package are located into /boot/incoming as bellow:
Because also (supposedly) the 5.15.19 files uses the same incoming method, when we upgrade the package, those incoming files are moved to /boot BUT the 5.15.19 are not removed because they are out of scope of installpkg - does not exists in this place in the tarball.

Now, the doinst.sh does the symlinks and we can isntruct it to look also for the previous kernel files, then to link them with the prefix "old-" obtaining something like:

For the kernel modules, no further doinst.sh processing is required, out of an "incoming" method.

This is enough to have ALWAYS the previous kernel preserved without stunts and even running LILO you can have always the previous kernel at disposition, on Slackware.

There is NOT about spoon feeding, or dependency resolution or automated graphical tools like in other distros.

It's all about HOW the kernels are packaged and this way described by me can avoid many, many boot incidents happening with the Slackware installations. By user mistakes, of course.

As homework, please explain me why and/or how this previous kernel preservation method is unSlackware. In detail.

PS. If you do not like the manual removal of the old kernels, there could be always invented a script ran by cron to automatically remove the old kernels and to leave only the latest (or N ny configuration) old kernel(s). Just like the openSUSE do.

3 members found this post helpful.

There are several solutions to this issue.

When the first kernel updates occur, I keep the original release kernel and modules from the install ISO on the system but remove them from package-management by removing the kernel-generic and kernel-modules files from /var/lib/pkgtools/packages.

After that, I can use upgradepkg --install-new on any newer kernel-generic and kernel-modules packages that come along safe in the knowledge that I have the option of booting the originally shipped kernel/modules as a failsafe.

A side advantage to this approach is that should the bootloader get screwed up, one can still boot from the install ISO with root= and it will find its matching modules.

1 members found this post helpful.

You could, but it might be missing the point. polls in general are bogus. Unless you can query every individual in the target demographic every conclusion you come to will be an approximation. However, but I was pointing out was not an issue with the poll itself, but rather how the poll was used to push an old Slackware stereotype. One that younger users (such as myself) are not huge fans of..

The reviewer clearly wanted to say that slackware is longer relevant in today's world. He even used a poll that essentially proves it by saying that users pre-2002 make up the largest piece of the userbase.

However... upon closer inspection of the numbers you can see that his percentages are calculated against a bunch of non-slackware users. Go deeper, you find that they are using 2-year increments to break down the userbase causing those users who are post-2002 to be under represented. This use of a poll to prove a point is not about the value of polling data, but rather about the misuse of polling data to support misinformation. The ultimate result makes newer/younger users look like we have a significantly smaller piece of the pie than we really do.


And his question also says but then proceeds to include over 800 votes from people who have never used Slackware. Even IF the data is accurate, framing it in this way lands firmly within the world of misinformation, and is a breach of the user's trust in Distrowatch.

3 members found this post helpful.

Two year increments are used throughout, but the main flaw is the "never tried" option.

The sample size is of course too small. Taking the figures as they are, at face value, as of writing 1289 have tried Slackware, 877 have not. Not useful data.

Looking at the figures for those who tried it, ignoring %:

1993-1995: 153 (7%)
1996-1998: 506 (24%)
1999-2001: 125 (6%)
2002-2004: 142 (7%)
2005-2007: 72 (3%)
2008-2010: 74 (3%)
2011-2013: 46 (2%)
2014-2016: 55 (3%)
2017-2019: 37 (2%)
2020-Now: 49 (2%)

We see that Slackware apparently "took off" a few years after launch, in 1996 - 1998 and then levelled off...

Almost like every other Linux distribution there is / ever was. One notable difference is that compared to many, Slackware is still going.

I really like it a lot. I've used it a few times on bare metal and in a VM. It has a minimalist design, and it's robust. Their unique package manager is interesting.

1 members found this post helpful.

From the way people in this thread describe the technical aspects of SOP with Slack I doubt you'd have much of a problem getting a FreeBSD machine running or maintaining it. No more than I would getting one of yours running anyway.

I've got a Beginners Tutorial with a target audience of someone who has never used the command line that takes you from installation of the Base System to a Fluxbox desktop using ports to compile third party programs. I provide examples of System and Security files that need to be edited once you hit the desktop along with a pf ruleset for general desktop use and one for people who use cupsd.

https://trihexagonal.org/

You can skip past the hand-holding and substitute pkg to do in 2-3 hours what might take me close to 24 hours to do compiling ports on the same machine. The experience you already have would make using ports easier, and that's good experience to have people who've only used pkg miss out on.


If you can still see the keyboard and the screen you're doing great.


I've got a Sony Vaio offline running FreeBSD 11.2-with XMMS playing music for me right now. They've removed it from the ports tree since then so I keep this version just to have XMMS.

3 members found this post helpful.

Indeed. I run -current but I have a 'safe' kernel that I compile by hand that trails behind the stock kernel by a few point releases. For example at the moment:

Always best to be cautious and take some responsibility for your own system...

The reviewer probably [removed]

An ad hominem attack is a logical fallacy, that is, when you attack a person or their character it does not invalidate their argument or point of view.
Your comment is not helpful.

13 members found this post helpful.

Regarding slackpkg, kernel, and kernel-modules upgrades: I always custom build a kernel that does not use an initrd. It makes little or no difference if I use a config from Generic and build it up, or from Huge and cut it down. I blacklist all kernel options in slackpkg excepting kernel-modules. In 20+ years I have never had a working kernel fail to boot because of a modules upgrade. I suspect this is largely from not using initrd as well as no auto updates to the kernel(s).

3 members found this post helpful.

slackass,
Per the rules,
Do not post if you do not have anything constructive to say in the post.

4 members found this post helpful.

I used to do that years ago when I had only 250 MB of RAM. I got so sick of watching those dots crawling across the screen as the Debian production kernel loaded. My custom kernel took a long time to build, but I only had to build it once and it loaded in seconds. But as I got more sophisticated hardware, the effort seemed less and less worthwhile. Nowadays I only build a kernel when I have to. That basically means LFS since I don't use Crux any more.

I got a bit of a jolt when I first installed Slackware and found that I needed to create my own initrd to go with the generic kernel. I could have built a kernel myself or used the huge one but I decided it was safer to go by the book.Fortunately I found a lovely script by Patrick that scanned my hardware and told me exactly what options I needed to use. I remember thinking then, "What a nice friendly system this is!".

5 members found this post helpful.

Agreed, hazel at least for some of my "normal" PCs. My laptop which I rarely ever use I just allow generic + initrd and it works fine. The new geninitrd script is indeed quite lovely but my Main box is tweaked for extreme performance and low latency, mainly for multimedia, gaming and DAW work so the gain from building in exact CPU options and high performance scheduling and timing is an important and substantial boost.

I don't really care much about boot times since all of my systems (excepting Windows) boot to usable Desktop in under 20 seconds. If I reset my main 15.0 system inittab to default to runlevel 4 it takes about 13 seconds. What I do care about is low maintenance, low automation and high performance. If I ran only one system on this box the maintenance per month would be a complete bore. Presently I have over 9 active, bootable systems for various reasons, some just to experience what is possible.

Even building new kernels is well under a half hour (possibly as little as 15 minutes as I haven't timed it exactly in ages... it's just fast enough to be of no consequence or concern) on this i5-10600K with M.2 NVME SSD as root ever since I learned about the "-jn" switch for "make". Comparing benchmarks this machine routinely competes with i9 machines running stock kernels (the i5 is overclocked +22% from base speed) . On the very same same machine Slackware 15.0 with the tweaked kernel benchmarks at least 25% faster and in some cases as much as 40% faster than in Win 10, even if the benchmark is on an NTFS partition so both can use the very same one, somewhat hindering Slackware which would operate much faster on XFS or ZFS.

So I totally agree that the days of having to work hard to get hardware working and building kernels that fit on a floppy are long gone. Linux in general and even Slackware in particular has definitely evolved into an extremely friendly system as you've noted while not losing it's power user base. That said, there is still substantial advantage to "deep diving".

3 members found this post helpful.

The Beginners Tutorial looks good, put together with real attention to detail and care. I had a quick look through it and I was interested in the pf ruleset - it has a really simple syntax - very intuitive and easy to understand. When I get time I will have a more detailed look at your guide and give installing FreeBSD a go.