User: Password:
Subscribe / Log in / New account

KS2012: Distributions and upstream

KS2012: Distributions and upstream

Posted Sep 6, 2012 21:56 UTC (Thu) by dlang (subscriber, #313)
In reply to: KS2012: Distributions and upstream by dlang
Parent article: KS2012: Distributions and upstream

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.

(Log in to post comments)

KS2012: Distributions and upstream

Posted Sep 6, 2012 22:09 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

"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

Posted Sep 6, 2012 22:33 UTC (Thu) by dlang (subscriber, #313) [Link]

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

Posted Sep 7, 2012 3:02 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

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

Posted Sep 7, 2012 11:24 UTC (Fri) by nix (subscriber, #2304) [Link]

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

Posted Sep 7, 2012 18:35 UTC (Fri) by dlang (subscriber, #313) [Link]

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)

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds