LWN: Comments on "KS2012: Distributions and upstream"

unionfs

henrich — Tue, 18 Sep 2012 17:49:20 +0000

Just a question, now we have aufs, do we still need unionfs?

KS2012: Distributions and upstream

xav — Mon, 10 Sep 2012 13:55:30 +0000

Do you know that you sound more pessimistic than I do ? :)

KS2012: Distributions and upstream

vonbrand — Mon, 10 Sep 2012 13:44:09 +0000

You misrepresent what folks are trying to do. The work in this area is to enable users a frictionless installation of their choosen distribution, and allow hachkish types to set up secure boot to handle self-compiled kernels without disabling it completely. I do agree that this whole mess is a misguided "security" feature at best, and a thinly veiled attempt from software-vendors/"content"-distributors to stab at controlling our machines at will at worst. In any case, it is being forced down out throats, we have to see how to make the best of it.

KS2012: Distributions and upstream

dlang — Fri, 07 Sep 2012 21:58:50 +0000

you can't both say that you want to keep things out of the kernel if they are expensive and say that you want to have everything that distros include merged upstream.

Frequently the reason something has not been merged upstream is that it isn't going to work well, isn't maintainable yet, or otherwise has some significant drawback to the code.

Also, the question that Matt Asks

> "If you don't expect an option to be enabled [by distributors], then why is the option even present?"

what distributions are you considering?

There are a lot of config options that make sense for OpenWRT that would be horrible for Fefora. The converse is also true.

KS2012: Distributions and upstream

dlang — Fri, 07 Sep 2012 18:35:09 +0000

RHEL is the leader in the "enterprise Linux" market, and as such, to a large extent their example drives that segment of the market.

That's why I specifically mentioned them, even though Suse and Oracle have the same policies (I don't know about Canonical)

KS2012: Distributions and upstream

xav — Fri, 07 Sep 2012 15:01:59 +0000

> Sometimes this means that to get some specific option that's got a particularly high cost for those that don't care about it, you have to compile your own kernel (and the distros that strongly discourage this really should be slapped, and yes, I am thinking of RHEL)

Just wait a bit for your new secureboot server. You'll have no other option left than running the distro-provided kernel.

KS2012: Distributions and upstream

nix — Fri, 07 Sep 2012 11:24:47 +0000

Quite. Note that if you have some module that you rely on that you need to use even when doing bug reproduction, but that is not included in the distro kernel, you can often take the distro config and kernel source and enable and compile that module, then load the module atop the distro kernel. This will usually work (modulo only those strange cases where enabling a module will also change code in the core kernel). (It's probably best to mention that you did this to the support people you're talking to, just in case it did break something, but I doubt that this approach will rouse too many hackles.)

KS2012: Distributions and upstream

rahulsundaram — Fri, 07 Sep 2012 03:02:28 +0000

Singling out RHEL seems strange since I don't think SUSE or Canonical or Oracle is any different in this regard. If you are using something compiled on your own, you can't really expect a vendor to support it. Especially for the kernel, considering the enormous number of experimental options, flaky drivers, random third party patches etc, it would be a nightmare.

KS2012: Distributions and upstream

dlang — Thu, 06 Sep 2012 22:33:37 +0000

when you are paying as much as RHEL charges for support for hundreds or thousands of servers, taking the attitude of "user our stock everything or you are on your own" is a very proprietary software way of looking at it.

I understand that this is easier for Red Hat to provide support for, but this is a pretty strict straightjacket that defeats many of the benefits of FOSS software.

KS2012: Distributions and upstream

rahulsundaram — Thu, 06 Sep 2012 22:09:48 +0000

"the distros that strongly discourage this really should be slapped, and yes, I am thinking of RHEL"

You are free to run your custom kernel in RHEL. If there are issues, you might be asked to reproduce it against the distribution provided kernel. Anything else would be a undue burden on support.

KS2012: Distributions and upstream

dlang — Thu, 06 Sep 2012 21:56:56 +0000

short form

if enabling A has a cost B saying "I want the benefits of A and I'm shocked that I'm having to pay the penalty B" == not good as well.

KS2012: Distributions and upstream

dlang — Thu, 06 Sep 2012 21:55:42 +0000

The problem is that sometimes it IS expensive to implement some feature.

so you have the choice of either having the feature available as an option, or not having it available at all.

Distros are not supposed to just enable every possible option, they are supposed to be selecting a reasonable set of options. Sometimes this means that they provide multiple kernels for you to choose from. Sometimes this means that to get some specific option that's got a particularly high cost for those that don't care about it, you have to compile your own kernel (and the distros that strongly discourage this really should be slapped, and yes, I am thinking of RHEL)

You also sometimes have options that the distro decides are probably important enough to enough people that they are going to make them be the default, and if you don't want to pay the cost of that feature, you will need to compile a kernel without it (again, if the distro doesn't offer an option)

In recent years Distros have in many cases been going too far in just enabling everything "because someone may want it" without considering, or testing the impact of the options.

upstream could be better in figuring out and communicating what the expected impact of options are, but that doesn't help if the Distros don't pay attention.

KS2012: Distributions and upstream

bronson — Thu, 06 Sep 2012 21:17:17 +0000

Because obviously distributions are going to enable those features. Claiming, "I'm shocked, shocked that anyone should enable this useful feature!" == not ok

KS2012: Distributions and upstream

mjg59 — Thu, 06 Sep 2012 18:47:57 +0000

Could you rephrase that? I'm not sure what you're asking.

KS2012: Distributions and upstream

hummassa — Thu, 06 Sep 2012 18:46:19 +0000

> Adding options that disable features when set to N is fine, adding options that enable features when set to Y and then being surprised when distributions enable them isn't.

Why "being surprised" == "not fine"?

KS2012: Distributions and upstream

mjg59 — Thu, 06 Sep 2012 18:19:25 +0000

You've misunderstood the context. Adding options that disable features when set to N is fine, adding options that enable features when set to Y and then being surprised when distributions enable them isn't.

KS2012: Distributions and upstream

smurf — Thu, 06 Sep 2012 17:53:44 +0000

You misunderstand. Not every kernel is built for a GP distro. Therefore the argument that any option that's not useful for distros simply shouldn't be there is fallacious.

KS2012: Distributions and upstream

mjg59 — Thu, 06 Sep 2012 17:27:32 +0000

Why would a general purpose distribution not want to support as many use cases as possible?

KS2012: Distributions and upstream

smurf — Thu, 06 Sep 2012 17:22:59 +0000

> "If you don't expect an option to be enabled [by distributors],
> then why is the option even present?"

Because not all kernels are being built by distributors of general-purpose Linux distributions.

Duh.