I'm sorry that you're upset... but these are your words:
If not for the meaning I took, what were you trying to say?
Yeah, because Slackware gives us the ability. Try having this discussion elsewhere!

What is this supposed to mean. This is a thread about initrd. Why single out my post? Did you some how think I was attacking you? I wasn't. I was simply following up on other post in this thread.

Exactly what it says, and nothing more.
No, not at all...

I suppose I was remiss in not explaining right from the jump that I'm comparing what might amount to a 2 hour build (that I'm determined to do anyway) once in a year's time, and within a kernel version easily and quickly trimmed in time ever after, to what can involve more accumulated time and aggravation if and when I encounter any problems with generating, using, or updating initrd. I simply prefer to take the few seconds to add the file system support that allows me to forgo initrd altogether as a kind of preventative maintenance. It's a nice relief that I never have to even think about it again.

I don't see any call for smugness and conflict.

You know very well that maintaining a correct initrd is actually the job of some properly made scripts. LuckyCyborg explained in detail how it can be done even in Slackware and you jumped at his neck in gang.

But I see that you gentlemen manage to make a controversial thread about initrds even without his help. The proof is this very thread.

I don't understand why you're beating around the bush about a task that should be solved by some Slackware scripts that aren't even that complicated. Maybe you find a meaning of life in doing the work of some mundane scripts?

2 members found this post helpful.

Well then. my only conclusion to "Try having this discussion elsewhere!" is that you considered my post to be off-topic. Even though there are other similar post in this thread. Or... maybe it was the "We all do things a bit differently.", a true statement, perhaps that was off-topic.

I was just showing how I create my initrd and to show appreciation to @Petri Kaukasoina for putting the idea in my head.

No, not at all... although I can see why you interpreted it that way.

The intention of that statement was to illustrate the point that you cannot have a discussion like this on other distro forums because most of them don't offer the same flexibility as Slackware.

1 members found this post helpful.

In the early 2000's, I used to build my own kernels because a standard distro kernel took forever to boot on my hardware. Of course the build took time too but after that booting was fast. Also the configuration for the build only had to be done once. Every subsequent build could be done by just using oldconfig, then leaving the actual build to chunter away while I did something else.

But now that I am old and have 4 cores and 4 GB, I don't bother any more. I just use Patrick's kernel and his lovely initrd generation script.

6 members found this post helpful.

Ah.. good point, my misunderstanding then. Thanks for the explanation. Glad I asked.

Are you accusing me specifically or is "you" meant to be general and plural?

What part of 2 seconds during a task I am already going to do for vastly more pressing reasons (Studio work benefits from a realtime kernel among other options) didn't you get? Why bother with a script when a single check box avoids the need entirely?

You chopped up messages into single line quotes that you strung a specific way instead of just reading what he said word for word. This distorts what he said. enorbet said he compiles a kernel anyway. Why is this important? Well for someone who comes from Slackware 7, they probably are aware of selecting kernels or compiling kernels. It's just what we did. If you compile a kernel anyway, which is what many did, you are selecting the drivers to make the system boot. Selecting the same drivers when running mkinitrd is moot. What do I take away from his message? If you come from Slackware 7 and reading now about initrd, you don't have to worry about it -- you can handle it already like you did before. It's nice to see this perspective is still present, to me who has been using initrd for a little while. Don't give people a hard time that have a different workflow.

Just observing that it appears that no one in this thread is using a 32-bit system, where it is harder to hack on /etc/mkinitrd.conf :-)
I have never been a fan of /etc/mkinitrd.conf. I have always preferred to do an initial manual run of mkinitrd on a fresh install, then work with /boot/initrd-tree/command_line.

Well, I may have removed excess verbiage, but I was trying to be quite careful to not change his meaning. His posts are still there, so you and future readers can easily refer back to them.
Yes, that point is well understood. For some historical context, enorbet quite often chimes in with this old chestnut when the subject of initrd is raised. I'll not repeat his reasons. They are openly disclosed in his posts above. Suffice it to say, that his opinion of initrds is well known around here.
I know, because I was there too. The problem is that modern process of compiling a kernel is substantially different to the process in Slackware 7.0, and the pay-off is not near the same. There are few reasons to compile a kernel these days, and unless one has specific needs (say low-latency for audio recording ), it is largely a waste of time and effort. Recommending it as a way to avoid building an initrd in somewhat counter-intuitive, since the process of compiling a kernel is the more difficult and time-consuming option these days.
Except for the fact that the process of compiling a kernel is a non-trivial exercise these days with insufficient payoff to make it worth spending one's time on. Of course you're welcome to disagree with that statement.
Hey, I don't disagree with you there. It's always good to have differing opinions and perspectives.

As I pointed out above, we in the Slackware community are lucky that we can have these types of conversations because users of other distros certainly cannot.

1 members found this post helpful.

Well that's a new one.

How is it more difficult to edit a text file on a 32 bit system?

That was more a comment on the suggestions.
Mugging boot and packages directories with
gives 'smp:smp'.

gives 'smp:smp-5.15.117-smp:smp-5.15.19-smp:testing'.

gives 'smp:smp'

Querying the source tree also has problems with kernel package naming.

These are not problems that cannot be addressed on 32-bit systems. I just wanted to caution about suggestions that will not work on 32-bit systems. Last I read, it is still intended to support 32-bit in Slackware 15.1.

After all, some people consider users need to be protected from shooting themselves in the foot.

1 members found this post helpful.