On Thu, Apr 14, 2022 at 8:18 AM JadoNena via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > The question is: how many users do we want to leave behind? Or: how many users must we leave behind because we can’t do the job. > > We are just users. Our expert development is for other professions than writing drivers and operating systems. > > My company has about 200 Fedora user PCs around the world. > Plus about 20 servers in real hardware and 30-50 in virtual. > More are in RedHat too but I am not talking about those here. > > We had decided on the RH+Centos+Fedora Eco system. > > All desktops and some laptops (that equals about 170) use NVidia graphics. In every case we use the NVidia drivers. They are built with the DKIM software. It is not convenient but it is worth the effort. We can rely on the NVidia software to work all the time. And we have access to the CUDA code and so on. > > For the servers plus the user PCs about 60% are on BIOS boot not UEFI. May be half of those are BIOS only. > > My company has a budget. We do the planning for 2-3 years. > It pays for developers salarys. And for new hardware. And for VPS rental costs. And for user training. > And for our Enterprise support products and services like RedHat. > > Unplanned and unexpected changes cost to my company a very large amount. > We always plan our strategy to control and best minimize that cost. > We must operate successfully for to pay those salarys and to purchase that hardware and services. > > All of this discussion waves a red flag at us. > We think we hear that Fedora has philosophy arguments about opensource and propietary and BIOS and UEFI. > We read the crazy mathematics about numbers of users based on I don't know what. > > But only a few people are talking about the real costs to users. > > Okay, the developers here are interested only in what makes the life easier for them. > And want to not have "3rd party vendors now dictate" decisions. > I can understand that theory too. > > But for here we deal with the real world where budgets require plans and hardware exists for years. > With this decision making the red flag means that "today & now" we must start with planning for alternatives to the RH+Centos+Fedora Eco system. > > We did not expect this from the RH+Centos+Fedora Eco system. > That maybe is our mistake? > > And that is all just one person at one company's opinion. > First: ***do not panic!*** Second: This is not a foregone conclusion yet. It's merely a ***proposal***, and one that most of the community has reacted negatively to. It may happen someday, but we *do* care about our larger ecosystem and user community. Chances are pretty good we'll have the capability to work with legacy BIOS boot on x86_64 machines for a few more years. Third: You pay for enterprise support from Red Hat, Inc. That means you have the ability to inform Red Hat through your business relationship of your needs. That subscription you pay for your RHEL systems allows you a direct relationship and influence over *their* roadmap. If you tell them that this would be a problem if it made its way into RHEL, they will account for that in their roadmap planning. Take advantage of that capability and talk to your account manager about it. It's their job to listen to your concerns and ensure that is accounted for. That's the value of the Red Hat Enterprise Linux subscription you pay for! As for anyone else looking at this thread with RHEL-tinted lenses as more activist RHEL customers, please direct your feedback to your account managers. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
