Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
> On 15/12/2022 13:34, Neal Gompa wrote: > > It should be fixed then. Please report this issue to dnf component. Using weak deps was our original plan, but problem is it broke due to https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect and we surely do not want to revert that. Also, it was less robust because it required dummy firefox and totem updates to cause the weak deps to be pulled in, and we regularly forgot to prepare those zero-day updates. > 2. Please do a network presence check before doing anything. Most users > store Wi-Fi passwords in a KDE/GNOME keyring and there is no network > access during the boot. The script will fail instantly. I agree that the script needs to be robust to the absence of network connectivity on first boot. That can happen for a variety of reasons. > 4. Please implement an opt-out switch. Some users don't want openh264 > from Cisco's third-party repository to be installed. I don't agree that it needs an opt-out switch. (a) It should not be behind the existing third-party software opt-out switch, because this open source software is built for Fedora, by Fedora, and signed by Fedora. It uses a third-party host purely for legal reasons. (b) Adding a second GUI configuration switch would result in a confusing user experience. (c) It's easy for technical users to uninstall openh264 and disable the repo if desired. (d) You can also do your first boot without internet connected, then disable the systemd service to stop it from running in the first place if you really want it to never get installed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
> On Thu, 2022-12-15 at 00:11 +0000, Michael Catanzaro via devel wrote: > > Well, except that we ship Firefox in the default OS image and to make > that play video, overlaying openh264 is *exactly* what's needed. Ah, drat... well there's not a lot of great options, then. We can (a) change it to use Fedora Flatpak and convince Cisco to host an extension, or (b) give up on the goal of not having any default overlays, or (c) give up on users being able to watch most videos. Please let's not do (c)? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
> One solution to reduce the time taken by client side layering and those > issues mentioned > above is to move the package overrides back to the server side by using a > layering > approach similar to the one used to build containers. This is the goal of > this change: > https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable. It > enables users to > make custom builds of Silverblue/Kinoite with their own selection of packages > and changes > and then to distribute them as an image to their systems, getting the full > benefits of > pure image based updates back if they don't do any local changes anymore. We can't do that on Fedora infrastructure, though, because we cannot distribute OpenH264. It would have to be done by Cisco. Seems like a no-go. But it might be OK to just not run fedora-autofirstboot for Silverblue/Kinoite. Thing is, system multimedia codecs are really a lot less important on Silverblue/Kinoite than they are on traditional desktops. What users really care most about is whether their _applications_ can play videos. That's a solved problem for anything using Flathub. For Fedora Flatpaks, the solution would have to be Flatpak extensions hosted by Cisco: overlaying OpenH264 on the host system won't actually accomplish anything useful. Even if you need it for a command line tool like ffmpeg, you're probably using a toolbx container for that, so again it's just not nearly so important on the host system. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
> Anyway, the effort that > went into that change proposal has established new expectations for any > change that will > impact system performance: the new flags should be benchmarked in an > environment where all > Fedora packages have been rebuilt with the new flags, so we can critique the > change based > on benchmarks that are not representative of real-world usage and reject it > if they show a > 2% performance hit, regardless of value to Fedora. If you don't like the idea > of > rebuilding all packages with the new flags, then maybe it was a mistake to > require > developers to do just that if they want to profile applications successfully. So I was quite upset when I wrote the above mail, seeing a new change proposal that admits it adds register pressure a few days after the frame pointer proposal was rejected for adding register pressure. Probably I should not send mails when angry. I don't actually support requiring the proposal authors to do the above work. `_FORTIFY_SOURCE=3` seems certain to make Fedora users safer. Regardless of what happened to the frame pointer proposal, it wouldn't make sense to block it from benefiting Fedora users. If we were politicians, then it would totally make sense to block Other Team's proposal unless Our Team's proposal gets accepted. (I support Team Frame Pointer. ;) But Fedora change proposals should not operate that way. (We all support Team Fedora here, after all.) This should go through. One more note regarding frame pointers. The `_FORTIFY_SOURCE=3` change proposal says "Per-application performance benchmarks may be useful in understanding the impact for those specific use cases." But this is not useful at all without an actionable way to figure out where performance problems are occurring, which requires functional profiling tools, which require frame pointers. Thank you _very much_ Neal, Fabio, and Zbigniew for your efforts to revisit that decision. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
No. He probably doesn't even know about this proposal yet, since it was just published yesterday. This is not the sort of thing that matters for desktop performance, where we care about orders of magnitude rather than a few percent improvement here or there. Even if extra bounds checking makes code 10% slower, which seems very unlikely, the benefit of the extra hardening would still be worth it. _FORTIFY_SOURCE=3 is going to make it harder to hack Fedora users, converting code execution vulnerabilities into denial of service vulnerabilities. That's worth a small performance cost. Reasonable educated users will want to make that trade even if we don't know exactly how much the cost is. Ordinarily I would not have even felt any need to comment on a proposal like this, except it comes immediately after the rejection of frame pointers, which leaves us unable to measure where Fedora performance problems occur without rebuilding the world. People who care about performance should be *very* upset about that decision. Anyway, the effort that went into that change proposal has established new expectations for any change that will impact system performance: the new flags should be benchmarked in an environment where all Fedora packages have been rebuilt with the new flags, so we can critique the change based on benchmarks that are not representative of real-world usage and reject it if they show a 2% performance hit, regardless of value to Fedora. If you don't like the idea of rebuilding all packages with the new flags, then maybe it was a mistake to require developers to do just that if they want to profile applications successfully. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
Red Hat's desktop performance engineer has repeatedly rejected use of DWARF as impractical and outlandish, including on this mailing list [1] and most recently at [2]. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UV65DSMPINEE6KWNI5MBH3MBQ26JHNNJ/ [2] https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1437#note_1191710138 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
