On Thu, Dec 22, 2022 at 7:32 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > Hi, > > > > If something is proposed for bare metal in the future, then raise > > > the problems at that point. It is unreasonable to demand that we > > > fix problems for a use case that is not in scope for what is being > > > proposed. Anything related to bare metal was explicitly out of > > > scope, precisely because it will massively increase the complexity > > > of what needs to be addressed, making the task infeasible. We need > > > an incremental path where we can tackle individual practical tasks > > > rather than trying to solve everything in one go. > > > > Yeah, and what happens when it gets punted again when that happens? I > > do not think it's unreasonable to bring these objections up front when > > this is clearly marked as a "phase 1" Change that implies UKIs will be > > used in more and more scenarios over time. > > I want UKIs becoming an option in more and more use cases. I don't > expect non-UKIs disappearing anytime soon though. From the updated > Change page: > > <quote> > long term plan: > Phase 1: Get the basic building blocks into place, so it is possible > to work with and develop for UKIs in virtual machines. > Phase 2+: Expand UKI support, tackling the use cases which depend on > a host-specific initrd or command line (see below) one by one. > Phase X: Once UKIs have feature parity with non-UKI kernels discuss > whenever they should be used by default everywhere (specific > use cases like cloud images might switch earlier). > NOT planed: remove support for non-UKI kernels. > </quote> > > I think at the end of the day this will be somewhat simliar to the Xorg > -> Wayland transition. First get basic support there, so it is possible > to try out stuff, figure what works, figure what needs changes etc. > Then a (probably long) phase adapting software, fixing bugs found etc, > making more more use cases being able to work with the new stuff. > Then at some point eventually flip the default. > > One notable difference is that with UKIs there isn't something simliar > to Xwayland, so flipping the default requires really everything being > able to work with UKIs. And flipping the default can only happen for > new installs, I don't think trying to migrate existing installs to UKIs > automatically is a sane idea. > Hmm, the updated Change is mostly okay. I disagree that you have any real security benefits since all the Secure Boot stuff in Linux is still in a bad place. I would like the Change document to be updated to include feedback about Secure Boot in there to further justify how restricted the scope will remain for Phase 1. Additionally, "discoverable partitions" fixes nothing for Fedora right now. There are two problems here: * We don't have a discoverable subvolume specification for Btrfs * Discoverable partition specification falls over dead with snapshots. Don't plan on using systemd-boot. I've said why before in other threads, so I'm not repeating it again. Drop locking out modified kernel command lines. That's pretty much a non-starter. If you want to pursue a Fedora Cloud image with UKIs, please bring it up with the Cloud SIG, keeping in mind the feedback I listed. -- 真実はいつも一つ！/ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
