On Thu, Jun 21, 2018 at 6:39 AM, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
I believe we're missing something fundamental here. If a program/service etc. requires specific hardware to workand 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 handlesituations where the hardware doesn't exist. This is systems programming 101 - and frankly I am abit 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx/message/KJSDTXYB7HGFPJJZ7DL34QQPU6MWN2R4/
