On Thu, Jun 21, 2018 at 6:39 AM, Stephen Gallagher <sgall...@redhat.com> wrote:
> > > >> I believe we're missing something fundamental here. If a program/service >> etc. requires specific hardware to work >> and it can't gracefully handle situations where that hardware is not >> present - it shouldn't be a default. >> >> The way to handle this (and other similar situations) is to take away the >> default status until it can handle >> situations where the hardware doesn't exist. This is systems programming >> 101 - and frankly I am a >> bit surprised it's a matter of debate. >> >> > No one on this list is disagreeing that the defaults should not degrade > the system. I *do* think that your response is an overreaction: just > because software may have bugs on your hardware doesn't mean that it should > be turned off entirely. If it's causing problems for a small subset of > users, they can be manually disabled. > > These services provide CONSIDERABLE benefit on the hardware that supports > it. Removing that as a default for those systems would be a significant > regression. That's not an acceptable solution. > > Most of the people on this thread seem to agree: we can conditionalize the > defaults so it is either skipped or at least does not mark the service as > "failed" if the necessary hardware is not present. People are already > working on doing this. > Stephen, I'm not disputing the benefit - and I very much appreciate the fact that people are working to conditionalize the defaults. What I do disagree with is your characterization that this is a bug. It is working as it was designed - and the design is faulty - and it's pervasive. I've encountered THREE different processes that aren't properly conditionalized. That's definitely not a bug - that's a systemic issue. Yes, AMD processors are not as popular as Intel, but they do exist in considerable numbers and most definitely should be considered when things are implemented as defaults; additionally... obviously... not everybody uses SecureBoot. My comment regarding taking away default status was in regards to this lingering for years. I personally don't believe that is acceptable. If one can't figure out how to fix things like this in a timely manner, then there is a problem.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KJSDTXYB7HGFPJJZ7DL34QQPU6MWN2R4/
