Stephen, Yes, unfortunately, it appears that is needed. I'll create a ticket.
Thanks Stephen. On Thu, Jun 21, 2018 at 9:08 AM, Stephen Gallagher <sgall...@redhat.com> wrote: > > > On Thu, Jun 21, 2018 at 12:03 PM Gerald B. Cox <gb...@bzb.us> wrote: > >> >> >> 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. >> >> > Well, there was also a failure of escalation path here. If this was going > on for years without a resolution, why wasn't it raised on this list or to > FESCo a long time ago? Individual maintainers have their own priorities and > time constraints and don't always address every bug that comes their way. > > However, had it risen up the chain, it's possible a group like FESCo might > take note and set down some rules/requirements. As it is, I think it's > probably time right now to move this to a FESCo ticket and see what we can > do about it. Gerald, if you feel strongly about this issue, please file it. > > _______________________________________________ > 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/YJOUFL2QBIQHZL5I52TLPZIA4VJLM6YK/ > >
_______________________________________________ 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/WB6HGXAVFXTF7YFQXZAT4TRL77KT5O73/
