I'll definitely own that "this is my conception". And that it's possible that I yet need a better understanding as to the next.

"Taint" doesn't mean an awful lot to me.

I see it when something is not fully "open source".

Of course the kernel developers cannot support when they are not allowed to see the source code.

Taint means to me that something may or may not happen.

I think taint is the code word used when the kernel developers are not allowed to see the source code.

Would you support, say a car, when you cannot see or know what is under this car's hood or if it even has anything at all under the hood? Hmm, we're going to call that one "tainted".

Is it still OSL for "open source lab"? or, has it changed by now? Is it still "open source", the kernel?

--
Alan.

It's no longer open source (the running kernel loaded in memory) when something "not fully open source" has been admitted to this already mentioned kernel space that's loaded in memory.

What are you supposed to call it then, ?? if it is no longer "fully open source", this live running kernel space that is loaded into memory.

Must be "tainted" or something since 100% of this (loaded into memory) "kernel" space is no longer the result of/from 100% of "fully open source" software.

--
Alan.

That link is broken, it should be:
http://www.slackware.ru/article.ghtml?ID=506

I agree with him (Pat V.) and with Linus T. They both know what they are doing.

Sorry, messed when pasting url. I'll fix it.

Actually, when I buy a car, I testdrive it. I usually don't care, how the engine looks, as it is "under the hood", but I do care how it sounds and accelerates... And even if there is no engine, at all: I don't care, when the car as a whole behaves as I want...

gargamel

I agree completely, as you say, you don't want untested patches. But patches for all eight (or so) big distributions (including Slackware) are usually tested quite well. And often find there way in future versions of the standard kernel.

So yes: Slackware is what it is, because it avoids distribution specific patches. And it's actually the "cleanest" among the top eight distros, to my knowledge. And finally, there have been instabilities in the standard kernel, as well. Sometimes, patches contributed by distributors fixed that.

I like Slackware so muche, because it avoids vendor patches. But it's not the only way to compile a good distribution.

gargamel

But if the car is difficult if not impossible to maintain, you hit a brick wall if you run into any problems down the road.

Melkor, these are "open source cars" :-) If that one breaks, just grab another and contribute to it and use it.

Er, oop, my mistake as in if we can't know what's under the hood equates to "not an open source car".

Well, you're on your own.
-------

My mistake, formerly linking support with taint.

I think support has nothing to do with it.

(I like your car though, the one that "motor or under the hood being optional, as long as the car works").

I strongly suspect that "taint" during bootup is merely limited to what I said in post # 17

which is that the "fully open source" loaded into memory running kernel space has just had something admitted into this space that is "not fully open source".

Taint is a way or very different issue from various other distro's kernel patches. Such distro patches usually are fully open source as well as the taint moniker also doesn't appear.

As to the distro patches. I wonder if these patches are 1. to kernel space or 2. to user space.

If they are # 2 then they are a patch that is added to the kernel which affects user space but it is not a "kernel patch" per se because it ultimately does not affect "kernel space".

Woopty doo. Kernel and user space must be layers (in the overall live running kernel space that's loaded into memory) these two spaces must be immediately adjacent to each other.

Good news is if the user space makes for trouble then just config up a different user space until get one that works alright. "Hacking", I think this is called/termed.

A great way to play, er, hack. If, down the road, such hack proves worthwhile then at that point consider to move it from user space into kernel space.

Perhaps it already right now works like that for I do not know how it currently works.

I'm not up on what they're doing with the kernel (except for more auto hardware detection).

Wasn't there a move at one time to move something out of kernel space and into user space?

--
Alan.