Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Why "being surprised" == "not fine"?
KS2012: Distributions and upstream
Posted Sep 6, 2012 18:47 UTC (Thu) by mjg59 (subscriber, #23239)
Posted Sep 6, 2012 21:17 UTC (Thu) by bronson (subscriber, #4806)
Posted Sep 6, 2012 21:55 UTC (Thu) by dlang (✭ supporter ✭, #313)
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.
Posted Sep 6, 2012 21:56 UTC (Thu) by dlang (✭ supporter ✭, #313)
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.
Posted Sep 6, 2012 22:09 UTC (Thu) by rahulsundaram (subscriber, #21946)
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.
Posted Sep 6, 2012 22:33 UTC (Thu) by dlang (✭ supporter ✭, #313)
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.
Posted Sep 7, 2012 3:02 UTC (Fri) by rahulsundaram (subscriber, #21946)
Posted Sep 7, 2012 11:24 UTC (Fri) by nix (subscriber, #2304)
Posted Sep 7, 2012 18:35 UTC (Fri) by dlang (✭ supporter ✭, #313)
That's why I specifically mentioned them, even though Suse and Oracle have the same policies (I don't know about Canonical)
Posted Sep 7, 2012 15:01 UTC (Fri) by xav (guest, #18536)
Just wait a bit for your new secureboot server. You'll have no other option left than running the distro-provided kernel.
Posted Sep 10, 2012 13:44 UTC (Mon) by vonbrand (subscriber, #4458)
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.
Posted Sep 10, 2012 13:55 UTC (Mon) by xav (guest, #18536)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds